Burp Scanner doesn't use cookie from session handling rule (makro)
So because I need some testcases for my new burp plugin I tried scanning the Hackerone bug bounty program of lyst.com https://hackerone.com/lyst . I found a potential bug in Burp's Makro/Session handling. The Makro is not always using the latest cookie that came back in a Set-Cookie header response.
- Burp pro burpsuite_pro_v1.7.17.jar
- Disable all scanner checks in "Active Scanning Areas"
- Configure scanner to only use 1 thread
- Add a throttle of 1 seconds between requests for active scans
- Add a throttle of 1 seconds to my plugin (it has such an option), probably doesn't matter as the problem occurs before my plugin even starts.
- Configure default session handling rule for cookies so that the scope includes scanner, extender, spider
- Add a session handling rule, scoped to all tools except Proxy, Restrict to requests containing "csrfmiddlewaretoken" parameter. Chose "Update current request with parameters matched from final macro response" to "Update only the following parameters:" csrfmiddlewaretoken. Leave the "Update current request with cookies from session handling cookie jar" to update all cookies. Chose to run makro.
- Actively scan the multipart POST request to /settings/ when saving the settings.
- Use Logger++ plugin (log from all tools) to see what's the problem (Tool that is causing the trouble is "Scanner" for alle the following 3 requests):
1. Correct: preflight Makro GET /settings/, server returns HTTP 200 with csrf token in HTML and Set-Cookie for csrftoken
2. Correct: Scanner sends POST /settings/ with correct sessionid=hp[...] in cookie and updated csrftoken in multipart and cookie. Important: server responds with a Set-Cookie: sessionid=nv[...]!
3. Incorrect: preflight Makro GET /settings/ is sent with incorrect/old sessionid (sessionid=hp[...]) in cookie. Server sends HTTP 302 and is terminating session because of wrong sessionid.
Not really related, but why is the scanner sending two requests when I disable all scanner checks?
I am having the same issue since upgrading to pro_v1.7.17 - i keep seeing the wrong cookie being sent by the scanner, which in turn is leading the scan not to work properly. Can we have an update from portswigger on this one?
We haven’t been able to reproduce this problem.
From your description, it sounds like you might need to enable the cookie jar to be updated from responses for the relevant tools (the checkboxes in the “Cookie jar” section).
If that still doesn’t work, instead of using Logger++, please can you use the Sessions tracer function to debug this issue? The sessions tracer will show a detailed description of the steps that are being carried out for each request, so that you can see exactly where the problem is arising.
I just reproduced the bug again. The effect is visible in Logger++ and in the session tracer. I see the effect I described above. I made two screenshots showing the first response to the scanner posts that includes the Set-Cookie. However, the session tracer does not have a step that says "Added X cookies from the scanner response to the cookie jar", and that's probably the bug. The second request of the makro where the wrong cookie is used from the cookie store is in the second screenshot:
So the problem here: The scanner sends a POST request and receives a Set-Cookie header but does not update the global cookie jar.
I actually have the correct tools enabled where the cookies jars should be used as described above. Please be more specific if there is another checkbox somewhere I could miss.
Glad you got things working. Let us know if you run into any other problems.