Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Confirming XSS high certain

Vlad | Last updated: May 26, 2016 08:29PM UTC

Hi, Burp scanner is detecting an XSS (high certain) with the following GET request and response: Request: /CGI/…. &CategoryID=123"onload%3d"alert(1)"456&CategoryName=Retail HTTP/1.1 Response: <LINK rel="canonical" href="https://SITE/CGI/....&categoryid=123"onload="alert(1)"456&CategoryName=Retail"/><!-- Canonical Link --> However, nothing happens with all browsers tested, including Firefox. Are there ways to really validate if this is a valid XSS?

PortSwigger Agent | Last updated: May 27, 2016 08:28AM UTC

The injected onload event should work, provided the resource is actually loaded successfully. You could try using onerror as well or instead, and see if that fires the alert.

Burp User | Last updated: May 31, 2016 04:56PM UTC

So in this case, there is no Javascript or any other scripts that are needed or required to fire the alert, am I correct? The response was part of a referrer URL. Other than copy pasting the URL to a browser, is there any other actions required to test it..?

PortSwigger Agent | Last updated: Jun 01, 2016 08:20AM UTC

The onload and onerror attributes are used to specify some inline JavaScript, so JS is needed to fire the alert. For your manual test, we would recommend using Burp as your proxy and looking in the history to confirm whether the request that you are generating matches the one that Burp reported, and also whether the response reflects the payload in the same way as Burp reported. If either of those isn't the case, then you'll need to investigate why not.

Burp User | Last updated: Jun 01, 2016 02:53PM UTC

In the original request by Burp, which is this one: /CGI/…. &CategoryID=123"onload%3d"alert(1)"456&CategoryName=Retail HTTP/1.1 There was not any <script> or JS parameters in the original request by Burp. So I just clicked on the reported vulnerability request by Burp and selected "Send to repeater". I also tried to open that original request in the browser (safari) which did not execute any JS..

PortSwigger Agent | Last updated: Jun 01, 2016 03:36PM UTC

Burp's proof-of-concept does contain some injected JavaScript, in the onload attribute. We recommend you look at the request and response that happen when you fetch the URL in your browser, to understand whether the correct payload is being sent and whether it is being reflected in the same way as Burp originally reported.

Burp User | Last updated: Jun 01, 2016 03:54PM UTC

I noticed that behavior. Some burp P.o.C do have JS scripts, while others do not. This is OK, different tests have different payloads. In my case, the payload is sent exactly as follow: "onload%3d"alert(1)" and the reply from the server does have exactly that payload "onload%3d"alert(1)", without any filtering taking place first. This is why it is being reported as an XSS by burp, and it makes sense. However, the payload on the response from the server is part of a href link link as shown below: <LINK rel="canonical" href=...Site.com/grk4u"onload="alert(1)"igl61&...."/><!-- Canonical Link and not part of a Javascript being executed by the browser. So the question is, would this be considered a false positive or not...

PortSwigger Agent | Last updated: Jun 01, 2016 03:58PM UTC

Understood. Please see our original reply: "The injected onload event should work, provided the resource is actually loaded successfully. You could try using onerror as well or instead, and see if that fires the alert." If the link isn't being (successfully) loaded, then you can try onerror instead of onload. Either way, this looks like a legitimate issue, not a false positive.

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