Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Validating XSS manually

Xavier | Last updated: Nov 01, 2015 05:40PM UTC

When I select the XSS vulnerability which Burp's scanner found, under "Request" I select "Show in Browser". Under the browser, I get the Javascript alert pop out. However, if I copy / paste the same exact URL (which has the JS script in it) and paste it outside the testing VM I am using which has Burp installed, nothing happens, regardless of the browser used. I am wondering why.

Liam, PortSwigger Agent | Last updated: Nov 02, 2015 10:02AM UTC

Hi Xavier Thanks for your message. This could be due to a variety of reasons. It is possible that the browser is using XXS filtering or URL encoding. It could also be due to the session state. We would recommend using the "Copy URL" function, rather than "Show in Browser". You should also use the Burp Repeater to manually assess what is causing the variation in response. Send the request from the scanner and the request generated by the "Copy URL" function to the Repeater and assess any differences in the communication. Please let us know if you need any further assistance.

Burp User | Last updated: Nov 02, 2015 02:04PM UTC

Thanks for your answer. Let us assume that the payload used was: 89a07"><script>alert(1)</script>2a9a7 Which parts of this payload should I see in the response to confirm an XSS vulnerability, and should it be seen exactly "as is", without any encoding?

Liam, PortSwigger Agent | Last updated: Nov 02, 2015 02:16PM UTC

Hi Xavier The entire payload should be reflected in the response. The elements of the payload that are likely to have been encoded are the special characters (e.g. "><). You should use the Repeater and the grep function to search for the payloads prefix to assess whether the payload has been encoded. We recommend using Firefox, as it does not include an XSS filter. You can use this page as a reference for checking which special characters are encoded by which browsers - https://code.google.com/p/browsersec/wiki/Part1#Uniform_Resource_Locators.

Burp User | Last updated: Nov 02, 2015 04:25PM UTC

Thanks. That is the part I am trying to confirm: If the browser does encode the <> characters (in the Raw response), what would that mean in terms of the validation of the XSS? Example: Request: POST /index/?1234d"><script>alert(1)</script>5678e=1 HTTP/1.1 Response: <form class="wrapper-form" action="/index/?1234d&quot;&gt;&lt;script&gt;alert(1)&lt;/script&gt;5678e=1" ... <form action="/index/?1234d&quot;&gt;&lt;script&gt;alert(1)&lt;/script&gt;5678e=1" method="post" Here we see the < encoded as &lt; and > as &gt; If the web app is not vulnerable, should it have any signs of the payload (even if it is not being executed)?

Liam, PortSwigger Agent | Last updated: Nov 02, 2015 04:45PM UTC

Hi Xavier The response you have presented would not be highlighted by Burp Scanner as an XSS vulnerability. If the browser is encoding the response then the XSS is not validated. You should use the original request / response produced by the scanner to validate the vulnerability.

Burp User | Last updated: Nov 03, 2015 02:18PM UTC

So when the browser encodes the response back from the server, it would be an indication the XSS script did not go through. It would have to be exactly as this to qualify: c1234"><script>alert(1)</script>4567

Liam, PortSwigger Agent | Last updated: Nov 03, 2015 03:11PM UTC

Hi Xavier If the XSS payload is not echoed unmodified in the application's response then the vulnerability is not validated.

Burp User | Last updated: Nov 03, 2015 05:08PM UTC