Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Cross-Site Scripting (Stored) Issue Inconsistency

Gabe | Last updated: Sep 14, 2017 02:07PM UTC

Hello, I ran a scan of an application and a Cross-Site Scripting (Stored) issue was reported at an Informational level. One of the parameters of the PUT request accepted a payload of j5kts<script>alert(1)</script>jveob, which was then returned in a subsequent GET request. After not changing anything about the application or the scanning options, I ran the scan of that endpoint (both PUT and GET), but the Cross-Site Scripting issue was not reported. My questions are: Is this something that's typical with this sort of issue? Please don't quote the other responses I've seen where you say you have tests built in to catch this issue. "It's not happening on my machine", is not an acceptable answer. How can I debug what is being scanned more easily to verify the issue is either present or not? I am able to manually store javascript alerts in other fields and parameters on this application. Why is it not showing up when scanning those endpoints as well? Thanks very much!

PortSwigger Agent | Last updated: Sep 14, 2017 02:15PM UTC

Hi Gabe, Thanks for your message. To detect stored XSS you need to first active scan the request that sets the stored value, then active scan the request that fetches it. Burp tries to store an interaction token in the value, and if this is detected subsequently, the pair of requests are tested more thoroughly. To debug this further, disable all the scanner checks except for Stored XSS (in Scanner > Options > Active Scanning Areas). You may also want to enable "Input returned in response (stored)". Then install the Flow extension from the BApp store. When you run an active scan, you can see exactly what Burp is doing using Flow. The scanner can struggle when the application only allows a single stored value. In this case, subsequent attacks can erase the interaction token. To help mitigate this, you can send the request to Intruder, clear all the position markers, set a single position marker to the field you're interested in, the do "Active scan defined insertion points". One last point, if an XSS issue is reported as Informational, that means we think the particular use case is likely to be non-exploitable. We still report these, as they can be useful hints for manual testers, and highlight code that is not best practice (even if non-exploitable). Please let us know if you need any further assistance.

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