Lab: CSRF where token is tied to non-session cookie
This lab's email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren't fully integrated into the site's session handling system.
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 two accounts on the application that you can use to help design your attack. The credentials are as follows:
- With your browser proxying traffic through Burp Suite, log in to your account, submit the "Update email" form, and find the resulting request in your Proxy history.
Send the request to Burp Repeater and observe that changing the
sessioncookie logs you out, but changing the
csrfKeycookie merely results in the CSRF token being rejected. This suggests that the
csrfKeycookie may not be strictly tied to the session.
- Open a private/incognito browser window, log in to your other account, and send a fresh update email request into Burp Repeater.
Observe that if you swap the
csrfparameter from the first account to the second account, the request is accepted.
- Close the Repeater tab and incognito browser.
- Back in the original browser, 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 your
csrfKeycookie into the victim's browser:
- Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses lab, ensuring that you include your CSRF token. The exploit should be created from the email change request.
scriptblock, and instead add the following code to inject the cookie:
<img src="$cookie-injection-url" onerror="document.forms.submit()">
- Store the exploit, then click "Deliver to victim" to solve the lab.