Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

False positives due to non-encoded parameters

floyd | Last updated: Mar 08, 2016 01:51PM UTC

This is probably related to the new features implemented when http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html was written. It seems to be that some new features of the active scanner are incorrectly sending payloads non-encoded and therefore produce false positives. An URL in the issue tab includes this kind of injection, visible 1:1 like this in the "request" part of the issue: http://example.com/?[...]n1rx3"accesskey="x"onclick="alert(1)"//hbbq Although the website is reflecting the " and this might lead to Cross Site Scripting and the finding is correct in Burp (the server *does* send it back like that), it is not in practice I think. Most browsers will encode the " to %22 before sending it to the server. In this case the server will send back %22. This is as well the case for Firefox, but the finding according to burp reads: The value of the AZERROR request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload n1rx3"accesskey="x"onclick="alert(1)"//hbbq6 was submitted in the AZERROR parameter. This input was echoed unmodified in the application's response. This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The proof-of-concept attack demonstrated uses the onclick event handler and the accesskey attribute to introduce arbitrary JavaScript into the document. Note that this technique requires the victim to trigger the access key using the key combination ALT+SHIFT+X in Windows/Linux and CTRL+ALT+X on OS X. It is specific to Firefox, and it will not work on other browsers. Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically. When I try the XSS in a Firefox manually (request - copy URL - paste into Firefox), I get the following HTML content from the server back (obviously no XSS): NOn1rx3%22accesskey=%22x%22onclick=%22alert(1)%22//hbbq6"> Same for Safari. However, the XSS *does* kind of work in Internet Explorer, when I request the same URL (IE is not encoding " to %22 it seems): <input name="target" accesskey="x" type="hidden" value="HTTPS://b2b.roche.com/google-rochepoc?resumePath=%2fidp%2fresumeSAML20%2fidp%2fSSO.pinglhurp" e42de"="" #nclick="alert(1)"> And when I turn off the XSS filter of Internet Explorer: <input name="target" accesskey="x" onclick="alert(1)" type="hidden" value="HTTPS://b2b.roche.com/google-rochepoc?resumePath=%2fidp%2fresumeSAML20%2fidp%2fSSO.pinglhurp" e42de"=""> However, as we already know, accesskey is not exploitable on IE :( So after all this is a non-exploitable XSS :(

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