First speaker, Tom Van Der Mussele from Verizon Business spoke about the “non-conventional attacks“. Tom explained that those types of attacks are difficult or impossible to be picked up by your favorite web scanners (Example: Nikto). Such tools expect more data like error codes or specific output to trigger alerts. Why? It’s difficult for them to know the difference between authorized and unauthorized data sets (Example: sent to two different users). Expecting a HTTP return code “200” is not enough. More and more applications use XML streams for dynamic data querying and look like a real fat client program like Google Calendar. The goal of such attacks is to escape the content of this specific end-user (the XML streams are interpreted by the end-user browser). How to achieve the attacks? By analyzing the structure of the XML sheet when performing input manipulation, cookie modification or by playing with meta-data like the user-agent. The classic scanner will try to replace value by funny stuff like “‘1>0–” but it can be very funny to replace the values by something other (fuzzing). Tom gave some examples of badly written web application which were front-end to legacy applications. It was easy to bypass the front-end by sending an unexpected key code like a function key. To resume his talk, there is no way to automate tests on modern web application. Main tools are an intercepting proxy like WebScarab (another OWASP project) and your brain!
The second speaker was Jim Manico: “The Ghost of XSS past, present and future“. Jim is an active member of the OWASP foundation and, amongst other projects, he’s the official OWASP Podcast editor. Jim is pushing for a participation of everybody into OWASP:
“We are doing bad and OWASP is good! It’s free and your can learn a lot of security stuff. If you don’t collaborate, you’re stupid!“
The message is clear. He started his presentation with a brief history of the XSS attacks then came to the conclusion that they will remain classic in the future. Why? Most web pages became more complex and attacks will become more difficult to solve. Classic methods to block XSS are sometimes irrelevant. Example, the characters < ‘ ” or & are sometimes used for “regular” purpose. If you block single quotes in your e-commerce application, you’ll loose all your Irish customers! The situation today:
- Untrusted data must be canonized
- Untrusted data must be validated
- Untrusted data mist be contextually sanitized/encoded
Then, Jim presented some frameworks to get rid of XSS attacks by auto-escaping template technologies:
- XHP from Facebook
- Context Sensitive Auto-Sanitization (CSAS) from Google
- Java XMT Template (JXT) from OWASP
The major trade-off for developers: They need to write highly compliant templates! Another protection is the usage of sandboxes:
At browser level, security can be increased by using the “Content Security Policy” which can be enabled by using the response header “X-Content-Security-Policy“. Jim is a developer and talked to developers. Not being one, some ideas were sometimes difficult to follow for me. If you are interested, Jim’s slides about the same topic are available here.
Finally, Christian Van Heurck introduced the Belgian CERT (CERT.be). This organization has two roles: reactive and proactive. They are the “Fire brigade of the internet” and are performing incident handling like the recent issue with dns.be. The Belgian CERT is in contact with other CERT worldwide and Christian insisted on the trusted relation established between all those organizations. To increase communications efficiency, it’s mandatory to meet and know the people. The best way remains to have some beers! It’s important to share the information. About the tools, they are some already in place like abusehelper.be (to automate process the incident notifications). But other projects are in the pipe to increase collaborations (no more details as I don’t know there official status).