Burp Suite User Forum

Create new post

False positives in XSS findings

apoorv | Last updated: Mar 16, 2018 03:43PM UTC

Hello, I use Burp scanner regularly and I observed two issues with reflected XSS detection. 1. Sometimes, burp sends the XSS payloads without URL encoding and reports the reflection as XSS. However, all major browsers perform URL encoding of special characters like < , > and "space" when you enter the URL in address bar. So, when producing a PoC, the payload is encoded and hence there is no XSS. This behavior of Burp was observed only when the context of reflection was the href attribute of anchor tag. 2. Burp sometimes flags a response containing reflected XSS payload as "reflected XSS" even when the content-type header in response is "application/json". Thank you for an awesome product. Regards Apoorv

PortSwigger Agent | Last updated: Mar 16, 2018 03:46PM UTC

Hi Apoorv, Thanks for your message. Two interesting suggestions. Regarding point 1, be aware that Internet Explorer does not URL encode the query string, so such vulnerabilities usually are exploitable. We do intend to add some text to the issue description in this scenario. Regarding point 2, I agree that such findings aren't exploitable on their own, although they can be chained with other vulns. What I think we'll do in future is report these, but with informational severity. I've linked your support case with the development story; we'll let you know when we make progress. Please let us know if you need any further assistance.

Burp User | Last updated: Apr 15, 2019 03:53AM UTC

Hi Team, Need some help to suppress false positives for XSS as below. Is there a way where i can check if the resulting page has a keyword like "Global Page Error" so that its not identified as an XSS issue. Lot of such issues are being handled in our application in a way that it points to an error after a malicious request with XSS is sent and displays this message. How can we do this ? Issue:  Cross-site scripting (reflected) Severity:  High Confidence:  Firm Host:  http://192.168.0.10:9090 Request: GET //Workflow'-alert(1)-'';alert(a); HTTP/1.1 Host: 192.168.0.10:9090 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cookie: user=corp%5Csunil.kumar Connection: close Response : HTTP/1.1 200 OK Server: Microsoft-IIS/8.5 X-AspNetMvc-Version: 4.0 X-Powered-By: ASP.NET X-UA-Compatible: IE=edge Date: Sat, 13 Apr 2019 10:32:11 GMT Connection: close Content-Length: 188 <h2>Global Page Error</h2> <p>The controller for path '/Workflow'-alert(1)-'';alert(a);' was not found or does not implement IController.</p> Return to the Page <a href='../'>Home Page</a>

Liam, PortSwigger Agent | Last updated: Apr 16, 2019 10:52AM UTC

Hi Amit Thanks for your message. There is no way to do this natively suppress issues via keyword searches. You can select a number of issues and tag them all as false positives. Burp Pro won't remember this action for the next scan. We have just released this feature for Burp Enterprise. You can register for a two month trial via our website: - https://portswigger.net/requestfreetrial/enterprise

Burp User | Last updated: Apr 17, 2019 04:42AM UTC

Hi Liam, Thanks for the response. Quick question : 1: Will this feature be part of Burp Pro in future ? 2: Can we have a rule engine where we can define such conditions on responses to handle these kind of scenarios and may be mark them as "Tentative" rather than "Firm" ? Since it will be difficult to always go and verify each and every link for this and then select each of them to make them as False Positive for every scan and report. In case there is such an add on please do let me know. Thanks

Rose, PortSwigger Agent | Last updated: Apr 17, 2019 07:48AM UTC

Hi Amit 1: Unfortunately, this is unlikely to become a Burp Pro feature. 2: Again, this is unlikely to become a Burp Pro feature. You could, however, create an extension to perform this functionality. It's worth noting that this may affect the coverage of your scan. Information can be found here: https://portswigger.net/burp/extender Please let us know if you need any further assistance.

Burp User | Last updated: May 09, 2019 01:36PM UTC

Hi Rose, Can we some how achieve this using macros where we can flag this as a False Positive ? There should be some capability to handle such scenarios within the framework since you will will also be doing similar logic for other use cases. Amit

Liam, PortSwigger Agent | Last updated: May 09, 2019 02:26PM UTC

Amit, what macros are you referring to? The only macros native to Burp Suite are used for session handling.

Burp User | Last updated: May 13, 2019 02:33PM UTC

Yes that is my point to have a certain type of macro which can find a certain page title or a regex on a response page and mark the vulnerability as a false positive. This way we will be able to remove the False positives using our own set of rules. Amit

Liam, PortSwigger Agent | Last updated: May 14, 2019 09:19AM UTC

This isn't a feature we will be releasing with Burp Pro. This is supported in Burp Enterprise: - http://releases.portswigger.net/2019/04/enterprise-edition-1015beta.html

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