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

Scanner - POST request results on a Different Page

klm | Last updated: Sep 25, 2015 08:01PM UTC

I have a webapp where, when saving edits to a particular page, a POST request is made to a simple 'FormSave' page. The server response is a simple 200, json response {"Success":"true"} (or failure if the request fails). This POST request is called via a particular script file that has been loaded as part of the page that is being edited. The script is also responsible for following up the POST request with a GET request for the page if the POST was a success (a reload of the page if you will). I am trying to find a way of testing/scanning this process other than manual POST requests (to the FormSave page) followed by a manual get request (for the page in question) and manually reviewing the results. Because of all the session tokens/cookies involved, to test the POST request, I've ensured those values are excluded from testing, I have the cookie jar updating itself within the scanning session and I have the scanner POST requests for the page being tested run through a POST macro to make sure to perform the follow up GET request. The flow appears to be working just fine but my question is whether or not the the scanner will detect the presence of a particular reflection style vulnerability (such as XSS) when the POST macro request is done; i.e will the scanner evaluate the results of a particular test request based upon the response to the POST only, the POST macro GET request or both? My fear is that the scanner is only going to evaluate the server response to the POST request which is just the simple success or failure message and not the actual page that the results of the POST would be seen on. I am hoping that the only way to really test this ISN'T by manually issuing POST requests and manually issuing the follow up GET request and manually inspecting the results. There are far too many parameters to do this in a short amount of time. Have I overlooked (or forgotten) an easier way to test against this scenario? Any help would be appreciated. Thanks,

PortSwigger Agent | Last updated: Sep 28, 2015 08:16AM UTC

It sounds like what you need is a session handling rule that runs a post-request macro. You can record a macro that runs your follow-up GET request, and create a session handling rule that is in scope for the POST request that submits the relevant data, and which runs your post-request macro. If you configure the rule to pass the final response from the post-request macro back to the invoking tool, then what Burp Scanner sees when it sends the POST request with the payloads is the response from the follow-up GET request.

Burp User | Last updated: Sep 28, 2015 01:33PM UTC