Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Cookie in dashboard issue activity not updating with cookie jar

Karl | Last updated: Nov 08, 2023 05:05PM UTC

Hello, Not sure if it is really a bug, but I found some strange behavior with burp scanner, let's make an example: I log inside a web application and I get a cookie like "PHPSESSID=ABC", then I log out the application and I log in again and obviously I get a new cookie value (PHPSESSID=DEF). I start an active scan by selecting inside my target a request, but since the request was the old one inside it still has "PHPSESSID=ABC", although the scanner works fine with cookie jar because I can see that the cookie used is PHPSESSID=DEF. But when a issue is found and reported in the dashboard "Issue activity" even if the scanner used the cookie PHPSESSID=DEF inside the request of the issues found is still present the cookie PHPSESSID=ABC, but this doesn't always happen, sometimes instead there is the cookie used by cookie jar. Application A, I login and I have a cookie PHPSESSID=6BBZDFGTTAAA, I send it to repeater, I go to cookie jar and change the value from 6BBZDFGTTAAA to test, then I launch the scan, burp finds the issuses and report in in "issue activity" but in some request there is the PHPSESSID=test and in other PHPSESSID=6BBZDFGTTAAA, although they all come from the same scanner activity. Thank you, Greetings

Michelle, PortSwigger Agent | Last updated: Nov 09, 2023 10:37AM UTC

Thanks for your message. To help us understand what you're seeing, can you send some screenshots showing this behavior to support@portswigger.net, please? When you see this behavior, are you always using an active scan? You mentioned that this doesn't always happen. Is there any pattern in the types of issues being reported when this happens? Have you been able to identify the request that caused the issue to be reported in the Logger tab of the scan task?

Karl | Last updated: Nov 09, 2023 04:16PM UTC

Thanks for your reply, The step I used to reproduce are the following: I go to a website and I interepct the first request, I send it to the repeater and the cookie is "EXAMPLE=123", then I go into cookie jar and manually change the value of the cookie to 234 (I do it manually just to make the process faster, it works also if the cookie jar updates itself). I get back to repeater and I click over "Do Active Scan", I execute the same steps over another domain and the difference is that in the first domain inside the "Dashboard issue" I see the old cookie, on the 2nd domain on few request I keep seeing the old cookie and on some other requests I see the new one. Maybe burp checks if the request was already inside the target, in case it is it shows the original one otherwise choose the modified cookie one (even if I tried all the scenario and the output is always the same)? Or there is some other mechanism involved such as if the scanner find a passive issue rather than an active payload such as SQL injection? Don't know if it it's really a bug or something done on purpose, anyway I am sending an email to "support@portswigger.net" to help you check this out. Can I be updated here on the forum or/and through the e-mail if you have an evidence about it? So I can understand too if this is a bug or not. Thank you

Michelle, PortSwigger Agent | Last updated: Nov 10, 2023 11:54AM UTC

Hi We've got your email and have just replied. Thanks for getting in touch. It would be good if you could also send us screenshots of what the cookie jar contains to help us understand the background of this scenario.

Karl | Last updated: Nov 10, 2023 03:59PM UTC

Hello, Thank you, I replied to the email. Greetings

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