Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Missed DOM XSS

Anthony | Last updated: Jan 23, 2015 07:41PM UTC

We were testing your DOM XSS scanning capability against test web sites (from the makers of Ra.2) and noted to obvious false-negatives that were missed. EXAMPLE 1: http://www.daspatnaik.com/test/demo/dom-xss-02.html RESPONSE 1: <html> <head> <title> DOM XSS 02 </title> <script type="text/javascript"> function timedMsg(callback) { if(callback){ var t=setTimeout(eval('callback'),500); return 0; } } function fire() { var call = location.hash.split("#")[1]; timedMsg(call); } </script> </head> <body onload="fire()"> <h4>Example Exploit: dom-xss-02.html#alert(1)</h4> <form> <input type="button" value="Display timed alertbox!" onclick="fire()" /> </form> </body> </html> EXAMPLE 2: http://www.daspatnaik.com/test/demo/dom-xss-03.html RESPONSE 2: <html> <head> <title> DOM XSS 03 </title> <script> function go(){ if (document.location.hash.split("#")[1]) { document.location.replace(document.location.hash.split("#")[1]); } } </script> </head> <body onload="go()"> <h4>Example Exploit: dom-xss-03.html#javascript:alert(1)</h4> <input type="button" id="btn1" value="Click Me" onClick="go()"></input> </body> </html> The other pages at this site where properly identified as vulnerable (http://www.daspatnaik.com/test/demo/dom-xss-(1,4-7).html. This behavior was seen on v.1.6.09 and with the "Maximum analysis time per item (seconds):" setting set to 600 seconds. These seem to be obvious bugs that should be detected, nothing obscure.

PortSwigger Agent | Last updated: Jan 26, 2015 09:46AM UTC

Thanks for these reports, which we've repro'd. By way of explanation: 1. The part that Burp isn't handling correctly is the interpretation of 'callback' (in single quotes). Burp currently treats this as a string literal, not a use of the symbol named callback. If you remove the quotes, then Burp does report the issue (which is a valid issue with or without the quotes). A planned future enhancement is to do further processing of string literals passed to the eval() sink, and essentially do a meta round of code analysis on that string (full lex/parse of its contents) and resolve their symbols in the context of the enclosing syntax tree. 2. Burp does currently report this as DOM-based open redirection, so is correctly tracking the taint from source to sink. What Burp currently doesn't account for is whether the tainted data can appear at the start of what is passed to the sink, or whether it only appears at some later point in the string. A planned future enhancement will let Burp track this information. Then, for some sinks Burp will report a different issue type depending on whether the start of the sunk data can be tainted (in this case, XSS vs open redirection). I hope that makes sense. We're planning to revisit the code analysis in the next few months, and address these and other enhancements.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.