1. 27th September 2012
Abraham Aranguren
@7a_
abraham@cure53.de
http://cure53.de

3. Review JavaScript code on the page:
<script>
document.write("Site is at: " + document.location.href + ".");
</script>
Sometimes active testing possible in your browser
(no trip to server = not an attack = not logged):
http://target.com/...#vulnerable_param=xss
http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html

4. Top security aware companies …
with DOM XSS reported via bug bounty programs:
• Google
• PayPal
• Facebook
• Etsy
• Yandex
•…

5. Are they searching for DOM XSS without pants like this?
this?
Phil Stevens - http://www.strengthguild.com/ http://www.ironradio.org/

6. The Problem
Websites have a LOT of JavaScript and DOM XSS is hard to find because:
because:
• DOM XSS happens on the client-side
client-
• Traditional HTTP fuzzing does not work for DOM XSS
• Traditional tools are unaware of client-side logic
client-
• Most tools cannot verify the DOM XSS exploit worked
• Most tools cannot find DOM XSS in a 100% automated way
• Even DOMINATOR Pro is only a manual testing tool for the Pro
DOM XSS often requires:
requires:
• User interaction: Click buttons, drag items, etc
• Timing constraints
A HARD problem to SOLVE

7. Created by
• Mario Heiderich (XSS PhD!)
• Gareth Heyes
• Abraham Aranguren
• Alfred Farrugia
• Frederik Braun
What are we doing differently?
differently?
• VSA is 100% automated
• We have tested we find MANY more DOM XSS vulnerabilities
• We can verify that the DOM XSS payload worked
• We are finding DOM XSS on the BROWSER -where JavaScript runs-
• We are verifying DOM XSS on the BROWSER -where JavaScript runs-
• We can tell you the line of code that is vulnerable
• We can tell you the JavaScript file where the vulnerability is
• We have the means to implement VIRTUAL PATCHING
Do you want us to scan YOUR site? ☺
site?

8. Demo Time

9. Q&A
Abraham Aranguren
@7a_
abraham@cure53.de
http://cure53.de