I have to explicitly mention that I really enjoyed all the talks that I visited, not only the talks summarized here.
Disclaimer: On the first day, I was visiting only the HackPra talks. This is because our institute is the organizer of HackPra (http://nds.rub.de/teaching/hackpra/), our company (www.3curity.de) partially supported this event...and there was free beer from GData.
Mario Heiderich: Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-application XSS
My first favourite talk was presented by Mario (heart-breaker, bon-vivant and security researcher from Berlin, see here for more superfluous descriptions http://owaspappseceurope2015.sched.org/speaker/mario_heiderich.1tmieewz). People, who already met Mario, probably know that he always presents some crazy XSS stuff. This was also the case for AppSec.In his talk, Mario presented what can go wrong when you copy your texts from rich text editors or office documents and paste them directly to your browser, for example to your gmail client. In that case, the browser gets not only the text, but accepts also addition style descriptions and elements. And these styles are usually described by some parsable language, e.g. XML.
One example gives us Open Office that stores the styles in a styles.xml document:
If we copy a text from such an Open Office document to the browser, the browser also accepts the above styles.xml file...and it tries to parse it. Mario managed to break several applications with this new approach and misused several rich text editors. See here for more information, in his slides: http://www.slideshare.net/x00mario/copypest
Btw, Mario cooperated in his research with a famous musician, who is also depicted on his slides, a few times (just do not be confused when you see him).
Talk: Mario Heiderich - Copy Pest - A Case Study On The ClipBoard, Blind Trust And Invis...
Nicolas Grégoire: Server-Side Browsing Considered Harmful
The talk of Nicolas was motivated by a server-side browsing capabilities and mitigations. Imagine you send a request to a server and force it to redirect the request to further URL (which also belongs to the server). This can give you a possibility for port scanning, or in better case, for remote code execution.
In his talk Nicolas presented that most of the servers try to mitigate server-side browsing with blacklists. Afterwards, he presented a few methods how to overcome these blacklists and what are the possibilities for an attacker: which protocols and ports can he misuse? which protocols are supported in which languages? ...and for me most interestingly, how can one overcome IP-based blacklists with alternate IP encodings.
Consider the following IP address: 169.254.169.254
This IP address can be encoded (on most of the systems) using the following alternatives:
- 425.510.425.510 (Dotted decimal with overflow)
- 2852039166 (Dotless decimal)
- 7147006462 (Dotless decimal with overflow)
- 0xA9.0xFE.0xA9.0xFE (Dotted hex)
- 0251.0376.0251.0376 (Dotted octal)
...and these encodings can be combined, e.g.: 0251.0xfe.43518
(btw., try to develop your blacklist now :) )
I really recommend you to take a look at the slides of Nicolas, you can find them here: http://www.agarri.fr/docs/AppSecEU15-Server_side_browsing_considered_harmful.pdf
Talk:
Nicolas Gregoire - Server-Side Browsing Considered Harmful
Tom Van Goethem: Issues And Limitations Of Third Party Security Seals
As mentioned on the beginning, OWASP AppSec is also very interesting for security researchers from academia. A proof of this give some high-quality research talks, including the talk about third party security seals given by Tom Van Goethem. The original paper was published at ACM CCS: http://securitee.org/files/seals_ccs2014.pdf (following texts and pictures are used from this paper).
"A third-party security seal is an image that a website can embed in its HTML code which signals to consumers that the website has been scanned by a security company and has been found to be without issues."
A security seal gives a website (e.g., a shopping website) visitor a guarantee that he uses a secure web site...well, kind of.
In their research, Tom et al. analyzed eight seal security providers. First, they found out that the penetration tests of the security seal providers are executed not that thoroughly. For example, some of them execute just a simple port scan. Thus, a motivated attacker could of course simply find additional vulnerabilities on the websites, even if the site is considered to be secure. Second, security seals can be used as oracles. If the security seal disappears from an observed website, the attacker knows he can execute an attack. Third, in some cases, the researchers could even force the security seals to report new vulnerabilities directly to attacker's website.
Please see the paper for more details.
Talk:
Tom Van Goethem - Issues And Limitations Of Third Party Security Seals
Talk:
Tom Van Goethem - Issues And Limitations Of Third Party Security Seals
Other recommended talks:
- Dirk Wetter - Security And Insecurity Of HTTP Headers
- Christian Schneider - Security DevOps - Staying Secure In Agile Projects
- Alex Infuhr - PDF - Mess With The Web
- Gareth Heyes - XSS Horror Show
- Michele Orru - Dark Fairytales From A Phisherman
* OK, I am just kidding, I was forced to do this by my supervisor :)