Lab: CSRF where token is duplicated in cookie

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

To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.

You have an account on the application that you can use to help design your attack. The credentials are: carlos / montoya.

Access the lab

Solution

With your browser proxying traffic through Burp Suite, log in to your account, submit the "Change email" form, and find the resulting request in your Proxy history.

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.

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, you can use this to inject cookies into the victim user's browser.

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

Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses, ensuring that your CSRF token is set to "fake". The exploit should be created from the email change request.

Remove the script block, and instead add the following code to inject the cookie and submit the form:

Want to track your progress and have a more personalized learning experience? (It's free!)

In this topic

CSRF CSRF tokens XSS vs CSRF SameSite cookies

All topics

SQL injection XSS CSRF XXE SSRF Request smuggling Command injection Directory traversal