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

Session Handling Macro Not Waiting for Response

Luke | Last updated: Mar 09, 2022 07:31PM UTC

Hello, I have configured the Burp session handling rules in project options to check if a session is valid and if not, issue a request containing a refresh token to an OAuth API to obtain a new access token. I am then attempting to pass the response of the macro request to the "Add Custom Header" extension and extract the token to replace the invalid token in the initial request. I've successfully done this exact process several times in the past, so I was not expecting to run into any issues. The "If session is invalid, perform the action below" macro is working correctly while testing in the macro editor; however, when I actually issue a request with an invalid token in the repeater and run the session tracer I can see the session handler correctly detects that the session is invalid, then issues the (refresh token) macro request, but the subsequent "response" tab in the session tracer is greyed out and it does not show that a response is received or trigger the "Add Custom Header" extension as configured. I've tried to replace the refresh token macro with other requests as well to ensure that it's not the specific request I'm making that's causing the problem, but I am still getting the same result. This seems like a bug to me because I've performed these steps successfully in the past. The root of the problem appears to be that the macro is not waiting for the response. When I test the request in the macro tester, the server takes about 2 seconds to respond. I wouldn't expect this to result in a timeout, but if that's the case is there any way to increase the amount of time the macro waits for a response? I don't think that's the issue anyway because I had the same problem when I used another request that responded within a couple hundred milliseconds. I'm using Burp Suite version 2022.1.1 (2022.1.1). Any help would be appreciated!

Liam, PortSwigger Agent | Last updated: Mar 10, 2022 07:55AM UTC

Thanks for your message, Lukas. When you have performed this process previously, were you testing the same application? Would it be possible to provide screenshots or a screen recording of your test in the Repeater? If so, you can email us at support@portswigger.net.

Luke | Last updated: Mar 10, 2022 01:36PM UTC

When I performed this previously, I was not testing the same application. However, I have tried multiple applications over the last day while debugging this issue, and run into the same problem. I emailed some screenshots showing the problem. Thanks!

Liam, PortSwigger Agent | Last updated: Mar 10, 2022 02:01PM UTC

Thanks, Luke. We'll follow up on the email thread.

max | Last updated: Mar 15, 2022 12:12PM UTC

I have the same problem. The final request remains pending and the repeater shows me "waiting", but from the session tracer I see the request correctly modified by the "ass custom header" extension, but the reply never reached the repeater. This problem was not there before, I was using this configuration before but with the burp update it stopped working.

max | Last updated: Mar 15, 2022 12:49PM UTC

OK, I solved it by disabling the "Enable HTTP/2 connection Reuse" option on the repeater. I hope this will be useful to someone else

Liam, PortSwigger Agent | Last updated: Mar 15, 2022 01:26PM UTC

Thanks for the tip, Max!

Luke | Last updated: Mar 15, 2022 01:47PM UTC

Thanks, Max! Disabling "Enable HTTP/2 connection reuse" was the solution for me as well. I had only been testing my session handling configuration in the repeater and assumed that meant it wasn't working for other Burp components (proxy, scanner, extender, etc), but I've now tested those and the session handling is working as expected. So it appears the issue was with the repeater specifically, not with the session handling rules or the macros like I thought.

Liam, PortSwigger Agent | Last updated: Mar 15, 2022 01:50PM UTC