OWASP AppSec Research EU 2013 – Hamburg

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.

Individuals contribute 20000 USD to make GNOME more secure and more privacy aware

rest

I’m so excited. I’ve just pushed the last update to the current Friends of GNOME banner. We received donations worth 20000 USD to make GNOME more secure and privacy aware. It’s so awesome to see so many individuals donating to make GNOME better for them and ultimately for all of us.

finished

We got 250 one-off payments and roughly 650 periodic payments from payment plans over the last 7 months. During that period, 52 payment plans were created with the average amount of 10 USD per month (the default setting). However, 51 plans were cancelled :-\ The one-off payments were worth 17600 USD and hence the average donation was about 70 USD.

Depending on how you do the math, the cost of taking the one-off donations was between 3.3% and 4.4%. I find that number surprisingly low, probably because I still can’t make sense out of PayPal’s fee structure. But there are probably some hidden fees that turn up once you actually want to do something with the money, i.e. have it wired somewhere.

A very big “Thank You” to all the donors who generously allow us to continue our mission to produce a Free Software desktop for everyone. You guys rock. Seriously.

The new GNOME board, which is already serving since the beginning of this month, will meet during GUADEC and probably call for bids some weeks later.