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

Strange behaviour with XSS payloads in Active Scanner.

Cláudio | Last updated: Nov 05, 2015 04:26PM UTC

I am having a strange behaviour on doing an active scan on this particular request: https://cld.pt/dl/download/5b8963fe-6f9f-4e4a-970d-a788e776258e/http_request.JPG Burp only does 10 requests and does not identify the XSS. I also have tried to define the insert point as the 11 value itself. Burp Scanner Options: Scan speed: Thorough; Scan accuracy: Minimize false negatives; Use Intelligent Attack Selection: No Active Scanning Areas: Only Reflected XSS option selected. Requests payloads sent by active scanner: #1: 11 #2: 11 #3: 119bbcf5bb683d8dc619 #4: 11alert(1) #5: 11b8ce7<a>b347e #6: 11b8ce7%3ca%3eb347e #7: 11�b8ce7<a>b347e #8: 11�b8ce7<a>b347e #9: 11a0a7164e4e%3e%3c #10: 11�a0a7164e4e>< The answer received is the same exact structure in the body with the reflected values. The content type of the response is "Content-Type: text/html; Charset=ISO-8859-1" Burp Version Used: 1.6.30

PortSwigger Agent | Last updated: Nov 06, 2015 09:15AM UTC

Thanks for this. Two observations: 1. The request states that the content type is a URL-encoded form submission, but it actually contains XML. It looks like this isn't the cause because Burp is correctly using entity encodings within the payloads, so is treating the insertion point as being within XML. 2. You say that the "answer received is the same exact structure in the body with the reflected values". If the exact payloads are being reflected, then this isn't an obvious XSS bug, since the reflection of URL-encoded or HTML-encoded characters can't be used for XSS in those payloads. If you think there is a valid bug that Burp is missing, please can you provide an example of a request and response extract that illustrates the bug?

Burp User | Last updated: Nov 06, 2015 11:35AM UTC

Hi Dafydd, Thank you for the feedback. I think that I did not expressed myself very well on the previous post. Let me give a practical example: https://cld.pt/dl/download/16b92534-9624-4209-823d-fd9844cd63ed/http_request_response.jpg This is the typical payload I was expecting Burp to do. If burp analyses that the response has reflected values and the content type is HTML, all the XSS payloads should be tried out. This is not the case. Only the 10 previous indicated payloads are used. My issue here is Burp should try out all XSS payloads.

PortSwigger Agent | Last updated: Nov 06, 2015 12:02PM UTC

Thanks - that makes it clearer what is happening. In its default settings, Burp creates an "entire body" insertion point for relevant content types, which includes XML. So in this situation, with the default insertion point settings, you should see Burp putting XSS payloads at the end of the XML in the body. (It will also place payloads within the XML structure, but as you've observed those payloads will be HTML-encoded due to their context, to avoid breaking the XML syntax.) When Burp sends the XSS payloads at the end of the XML, does the application still reflect the input? If so, Burp ought to be reporting the XSS. (Another factor here is that you can't normally make an XML request cross-domain. The exploitability of any issue here might depend on if/how the app validates the content-type header.)

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

I triggered the Active Scan by going to the proxy and indicating to do an active scan on that request. Burp does not send XSS payloads after the body. Only inside it. The requests are the same 10 for each of the insertion points. In my particular scenario, tags after or before the main body of the XML would invalidate the request. I understand that some payloads should follow the right structure of a XML, but all payloads should be tried out,such as a simple XSS poc with the <script> tags, specially to understand if an application has a different behavior with something that was not expected. In this case Burp misses a trivial XSS. My current scanner configs are: Attack Insertion Points: Only "Body Parameters Values" and "Entire Body" are selected.

PortSwigger Agent | Last updated: Nov 06, 2015 02:14PM UTC

Sorry for the delay in getting back to you. We've been giving this some thought and have some ideas for making Burp detect this issue. We'll update this ticket when we have some progress to report.

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