Posts Tagged ‘owasp’

OWASP AppSec Research EU 2013 – Hamburg

Friday, August 30th, 2013

I was lucky to be able to attend OWASP’s AppSec EU Research conference in Hamburg, Germany. I’ve been to the one in Dublin and looked forward to the German edition. With 400+ attendees I thought that the conference was surprisingly well attended. And rightfully so. The people organising it were doing a fantastic job. Everything seemed to work smoothly and although I volunteered I was able to see a good bunch of talks.

The program looked promising and most of it was quite good. I was told that there will be recordings soon which is also quite remarkable. The video team definitely deserves a round of applause. So does the venue. We were locked up in the upper most floor of the Emporio, which allowed for awesome views over Hamburg. Although I’ve lived in that beautiful city for so long, I didn’t realise one could actually get such a nice view from a conference room. Sometimes it was hard to not get distracted by the views during the talks…

The first talk I attended was given by Paul Stone and he showed us how he reads your browsing history and pixels. This is amazing work. He examplified the significance of these attacks by showing how to obtain the Google+ profile information. His trick was to apply some obscure SVG filters to HTML elements. Based on the amount of time it took to do so, he could deduce whether the pixel was black or white. He leveraged that possibility to read source code by analysing properties of the fonts used and what key pixels exist to tell which character was rendered. So amazing. If you have time to only watch one talk, it should be this one.

The next talk on Burp was given by Nicolas Gregoire. I was not so impressed, because it was mainly a tutorial as to where to click to make it do $things. But I was told by people actually using burp that it was insightful and interesting.

Taras Ivashchenko from Yandex was talking about Content Security Policy (CSP). I was surprised to learn that Yandex have their own browser. And that their bigger service is mail. I thought it was search. The title of the talk promised an answer to the question whether the CSP was actually useful. He didn’t deliver though. But it gave an insight to how a big company with a well used web site deploys CSP. Unfortunately, he couldn’t tell how much effort it actually was and whether it was actually an economical decision.

He reminded us that the CSP was a second line of defense. It’s not a solution to broken code which does not escape properly. It’s merely a parachute to land safely in case you screwed up. I found it interesting that he mentioned ten contexts that one would potentially need to escape for. My conclusion is that JavaScript is probably the worst language to use on the Web as it offers only two escaping functions. And not even for the most important contexts like plain HTML. I’m curious to learn about all ten contexts. Another interesting idea he presented was that CSP may allow inline scripts if they are “signed”. The “signature” was a random string that is shipped with a header and the script element on the page must carry a “nonce” attribute with that random number.

Matryoshka was the theme of Eduardo Vela’s talk. The Google guy showed various hacks, one of them was “wrapping overflow leaks on frames (wolf)”. It was possible to get an idea of the word rendered on a page with mocking around with the page’s width and height. With the information about the dimension you could detect when a scrollbar was placed and hence can find out how wide the wrapped word was. He claimed that especially new performance APIs were going to create a whole lot of privacy related issues. Another problem was the lack of a JSON format validator, he said. Several problems such as deep array parsing would currently exist. If you serialise a big enough array, you could get into trouble, he said.

A great show was delivered by Mario Heiderich talking about the The innerHTML Apocalypse. He compared the three currently distinguished types of Cross-Site scripting (XSS), namely reflected, stored, and DOM-based XSS, with the three horsemen. The fourth horseman, he said, were “mXSS”, mutation-based XSS. Essentially it is circumventing HTML filter libraries by using mutations done by the web browser.

The problem, inappropriately shortened, was that people use “document.write” to inject elements into the DOM instead of using proper DOM APIs. But that is, he claimed, due to convenience. A call to “document.innerHTML” was so much easier than calling out to “createElement”, “addChild”, etc. And it is true. Too bad that, as we’ve learned earlier, using JavaScript is totally inappropriate to write web applications as it cannot even escape for the HTML context. Anyway, the browser is quite relaxed and accepts slightly malformed HTML. It will even do optimisations or transformations for you. Internet Explorer, for example, will happily drop quotes around arguments to HTML tags for you.

To make the long story short: CSS escapes are badly handled in many of the existing escaping libraries. So you could break out of the element’s contexts by cleverly using some CSS escape sequences. Also, SVG should be avoided at all costs. It’s a can of worms, he said. You could do so many evil things within SVG, like executing JavaScript, loading remote resources or accessing attributes.

OWASP AppSec Reseaerch EU 2013 was good fun. The location was absolutely fantastic. Probably the most noble venue I was at to have a conference. The organisation looked flawless and everything seemed to work out smoothly. Thanks for giving me the opportunity to meet great people. I hope to be able to do so for the next conference.