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

Stored XSS Where Entry and Exit Points Differ and Payload Not Included in Reponse

Jeffrey | Last updated: Oct 26, 2021 10:36PM UTC

I commonly run across a scenario where I need to test a request for stored cross-site scripting, but the application only allows a single stored value, such as a user first name. When the payload is included in the response or a redirect occurs, Burp Scanner seems to figure out what to do. However, responses of this type are becoming increasingly rare in modern web applications. My question is, is there a way to tell burp which entry point to use for the payload and which exit point/URL to check for the stored value? I read through the following resources: - <https://portswigger.net/web-security/cross-site-scripting/stored> - <https://forum.portswigger.net/thread/cross-site-scripting-stored-issue-inconsistency-80df9b36> - <https://forum.portswigger.net/thread/stored-xss-detection-tweaks-747a32c8> The documentation link indicates that this method of testing is exactly what's needed: > To comprehensively identify links between entry and exit points would involve testing each permutation separately, submitting a specific value into the entry point, navigating directly to the exit point, and determining whether the value appears there. But then goes on to say that it isn't practical, so Burp just looks at the response.

Liam, PortSwigger Agent | Last updated: Oct 27, 2021 03:23PM UTC

We've asked our Research team to consider the points in your forum post. We'll get back to you if they have any feedback. Thanks!

Jeffrey | Last updated: Oct 29, 2021 04:21AM UTC

@liam, thanks for the reply. Assuming its not already possible, I can think of a few implementations: 1. I could accomplish this with intruder if we could configure it to make an additional request that our grep would apply to. This would be a little more manual, but definitely doable. 2. I can think of a whole bunch of aspects of Burp that could benefit from flows or chains of requests where currently only a single request is permitted. Its possible the Research team already had this in mind for the navigation recorder and the recorded login functionality was only the first tool to make use of it. But if you could import a sequence of actions/requests and then select one or more of those that the scanner should alter while performing the chain of actions, that would cover this use case and many others. I'm sure this is nothing new to you, but through I'd offer my thoughts.

Liam, PortSwigger Agent | Last updated: Oct 29, 2021 12:15PM UTC