Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

In consistency while reproducing XSS vulnerability

Karthik | Last updated: Apr 22, 2015 07:22AM UTC

Burp has reported some XSS vulnerability for a website. For the below discussion let us use this URL entry www.example.com/nagiosxi/reports/execsummary.php/19537"-alert(1)-"28ffd?hostgroup=&host=&startdate=&servicegroup=&reporttimesubmitbutton=reporttimesubmitbutton%253dGo&enddate=&reportperiod=today Case 1: Right click on a XSS Vulnerability result entry, I use the "Request in Browser >> In current browser session" and I am able to see the vulnerability in the response (script got executed) This was the input given - 19537"-alert(1)-"28ffd As an output I saw an alert box with 1 in it. Everything is working fine Full Request header GET /nagiosxi/reports/execsummary.php/19537"-alert(1)-"28ffd?hostgroup=&host=&startdate=&servicegroup=&reporttimesubmitbutton=reporttimesubmitbutton%253dGo&enddate=&reportperiod=today HTTP/1.1 Host: www.example.com Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Referer: https://www.example.com/nagiosxi/reports/execsummary.php Cookie: nagiosxi=r3b0d3rod8uhgehkrm24oii754 Case 2: Now, I copy the same vulnerable URL and paste it in browser and press go - the page loads, but the vulnerability is not seen (script is not getting executed) Full Request header GET /nagiosxi/reports/execsummary.php/19537%22-alert(1)-%2228ffd?hostgroup=&host=&startdate=&servicegroup=&reporttimesubmitbutton=reporttimesubmitbutton%253dGo&enddate=&reportperiod=today HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Cookie: nagiosxi=r3b0d3rod8uhgehkrm24oii754 Connection: keep-alive Note: In both the cases the URL is same and it is a GET request. Case 2 doesn't produce the result (script getting executed) whether burp is still used as proxy or not In both the cases the source code contains the script as it was in the input in the same location. Same browser is used in both the cases Cookies in the browser and cookie.jar is same for both the cases (I even cleared the cookies before performing this test) Though I could see some differences between the request headers I am not sure which one is causing this change (I tried matching both the requests but no luck) Question 1: Could you please help to understand the difference in behavior when accessed the URL from browser vs using the request in browser option ? Question 2: Does this mean that these vulnerabilities can be exploited / or shown demo to a developer only with the help of burp ?

Burp User | Last updated: Apr 22, 2015 08:02AM UTC

Ok...I guess I found out the issue. Case 1: payload goes as 19537"-alert(1)-"28ffd Case 2: Payload goes as 19537%22-alert(1)-%2228ffd I can change the payload in case 2 similar to case 1 and vulnerability appeared (script got executed) While this is out of scope for burp, Could someone help me how to ensure firefox (or any browser) sends characters in URL without encoding ? In firefox, Chaging network.standard-url.encode-utf8 and network.standard-url.escape-utf8 to false doesn't help

PortSwigger Agent | Last updated: Apr 22, 2015 08:07AM UTC

You could try using IE, which doesn't URL-encode the < and > characters in URLs.

Burp User | Last updated: Apr 23, 2015 11:53AM UTC

Hello, Thanks for the answer. Even with Internet Explorer I am seeing the same behavior. The URL is getting encoded. Any guess ?

PortSwigger Agent | Last updated: Apr 23, 2015 01:26PM UTC

Ok, I just spotted that your payloads are going into the URL file path (not the query string). Browsers do handle URL-encoding differently within the file path, and I believe that all browsers URL-encode characters like < > and ". If you can't find a recent browser that sends the required characters in raw form, and the attack doesn't work with them URL-encoded, then the issue may not be exploitable. We're going to investigate this further and if necessary modify Burp Scanner's handling of characters encoding within the URL file path, to avoid any false positives.

PortSwigger Agent | Last updated: Oct 06, 2015 03:07PM UTC

Hi Karthik Just to let you know that in today's release we've modified Burp's URL-encoding of characters within the URL file path to replicate what is done by current browsers. Hence, Burp should no longer report false positives for XSS that involve characters like < being literally placed into the URL. Thanks again for your feedback, and so let us know if you run into any other problems.

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