Burp Suite User Forum

Create new post

Burp not working correctly if WAF uses connection reset

Christian | Last updated: Dec 13, 2016 10:25AM UTC

Hi, I am currently expecting a strange issue with Burp, which affects the active scanner. I have used the active scanner against a web application which is protected by some kind of WAF. The WAF works like this: if the request contains "alert(" (without quotes), then reset connection I have analysed the requests with the "Flow" extension and it looks like that a few XSS payloads are actually working, e.g.: randomstring"> or javascript:/*</script><svg/onload='+/"/+/onmouseover=1/+/[*/[]/+((new(Image)).src=([]+/\/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\.burpcollaborator.net/).replace(/\\/g,[]))//'> However, no XSS issues are reported within the active scanner. I assume that everything should work fine if a connection reset is handled as a "blank page" instead of an "error". I am happy to provide a testcase if needed This issue might be related to: https://support.portswigger.net/customer/portal/questions/16696410-scanner-ignore-errors-and-continue Many thanks, Christian

PortSwigger Agent | Last updated: Dec 13, 2016 11:23AM UTC

The payload you identified as working is one that Burp uses to detect stored/blind XSS, and it requires user interaction to view the response containing the payload. If a user views this response, then their browser will make a request to Burp Collaborator, and Burp will retrospectively report the issue if it is still running. If Burp finds that its standard reflected XSS payloads containing "alert(" are being blocked, then it will try others, such as "prompt(". If you are monitoring requests made by the Scanner, do you see other payloads following the failure of "alert("? Does Burp appear to be executing its normal reflected XSS logic against the reflection point?

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