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

Second Order Testing | Burp Scanner

Philip | Last updated: May 28, 2018 12:01PM UTC

I'm trying to setup a session rule for Burp Scanner, is it possible to create a session/macro for the following scenario? Scenario: Webpage #1: POST Request http://example.com filename=payload Webpage #2:GET Request http://example.com?view=payload Basically how to I take the payload from #1 and insert it into #2 view parameter and analyse that response?

PortSwigger Agent | Last updated: May 29, 2018 06:53AM UTC

Hi Philip, Unfortunately, I don't think it's possible to configure this using Session Handling Rules alone. If you're prepared to do some coding, you could write a small extension. The way I'd structure it is: configure the GET request as a macro and configure a session handling rule to invoke that as a post-request macro. I'd have the extension register an IHttpListener monitor outgoing POST requests for the filename payload, and update outgoing GET requests to update the view parameter. If you have a go an implementing this, I'm happy to help.

GarlicCheese | Last updated: Feb 14, 2020 06:29AM UTC

I've previously replied to this, but apparently it has been removed. I'd love to see this happen. I've had this exact case a number of times during pentests. For instance with an API, offering separate calls to save (POST /item) and view items (GET /items). POSTing a new item would only yield an empty 200 OK or 500 Server Error, but viewing the stored item with GET /items would offer a much better insight in the applications logic and possible vulnerabilities.

Michelle, PortSwigger Agent | Last updated: Feb 14, 2020 03:41PM UTC

I'm sorry your previous post has disappeared, I'd like to assure you it wasn't deliberately removed, we're checking out what happened there. So we can be sure we understand what you're looking for properly, could you tell us a bit more about the use case you have and how you'd ideally like Burp to behave in this scenario? If there's any information you'd rather not post publicly you can always email us (support@portswigger.net)

GarlicCheese | Last updated: Feb 20, 2020 10:08AM UTC

No worries, I was not thinking so. I believe my previous post was sent without use account, right before the recent changes were made. Right so. Burp Scanner takes a request and analyses the applications behavior form the corresponding responses, thereby deducing the vulnerabilities. What I'm looking for is a feature to consider an alternative response, instead of the response directly received from the tested request. Very much like a second order SQL-Injection and like `sqlmap` handles these (i.e. sqlmap -r first-request.req --second-req=second-request.req). I've tested a number of applications, where this could come in very handy. For some minimalistic APIs, the Burp Scanner does not really work. For example: POST /item [...] item=<testing-parameter> will always respond with 200 OK (no body) or 500 Server Error (no body). But the following: GET /items would then return all previously posted items, offering insight on how the application handles the sent "<testing-parameter>". I imagine this like a Burp Scanner option, where you can add a second request, from which the response should be considered. So Burp Scanner would: - Send Testpayload#1 to Request#1 (POST /item) - Wait for the request to complete - Check response of Request#2 (GET /items), considering Testpayload#1 I hope I could explain the scenario a bit better now.

Michelle, PortSwigger Agent | Last updated: Feb 20, 2020 03:31PM UTC