Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp Scanner doesn't use cookie from session handling rule (makro)

floyd | Last updated: Feb 24, 2017 10:19AM UTC

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. My setup: - 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. - For makro use a GET request to /settings/ URL with no further URL/Body parameters. Parse out csrfmiddlewaretoken from the hidden form field (custom parameter). Leave the "Add cookies received in responses to the session handling cookie jar" and "Use cookies from the session handling cookie jar in request" enabled. - 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?

PortSwigger Agent | Last updated: Feb 24, 2017 02:01PM UTC

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.

Burp User | Last updated: Feb 27, 2017 01:49AM UTC

Hi, 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? thanks, Dougal

Burp User | Last updated: Feb 27, 2017 11:35AM UTC

Hi Dafydd 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: https://dl.dropboxusercontent.com/u/3378931/first-request.png https://dl.dropboxusercontent.com/u/3378931/second-request.png 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.

Burp User | Last updated: Feb 27, 2017 11:37AM UTC

Wait! I found another checkbox!

Burp User | Last updated: Feb 27, 2017 11:45AM UTC

Ok, so there are actually more settings where you can specify which tools should update the global cookie jar and the scanner was missing. Sorry for the fuzz, problem was sitting in front of the keyboard

PortSwigger Agent | Last updated: Feb 27, 2017 11:51AM UTC

Glad you got things working. Let us know if you run into any other problems.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.