CSRF where token is duplicated in cookie

Description

This lab’s email change functionality is vulnerable to CSRF. It attempts to use the insecure “double submit” CSRF prevention technique.

Reproduction and proof of concept

  1. Open Burp’s browser and log in to your account. Submit the “Update email” form, and find the resulting request in your Proxy history.

  2. Send the request to Burp Repeater and observe that the value of the csrf body parameter is simply being validated by comparing it with the csrf cookie value.

  3. Perform a search, send the resulting request to Burp Repeater, and observe that the search term gets reflected in the Set-Cookie header. Since the search function has no CSRF protection, it can be used to inject cookies into the victim user’s browser.

  4. Create a URL that uses this vulnerability to inject a fake csrf cookie into the victim’s browser:

/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None

  1. Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defences lab (above), ensuring that your CSRF token is set to “fake”. The exploit should be created from the email change request.

  2. Remove the auto-submit script block and instead add the following code to inject the cookie:

<img src="https://0a6500c504aae380c59e678d002000fb.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>

Copy HTML and put it in the body of the Exploit server form:

CSRF

  1. Store the exploit, then click Deliver to victim.

Exploitability

An attacker needs to use the exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address, and access to two accounts.

Last update: 2025-05-12 14:16