CSRF where token validation depends on request method
--
We will cover how to perform the CSRF exercise from PortSwigger labs in this post, where the request method determines the token validity.
Learning Path:
Lab description:
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
Steps:
Step 1:
Upon entering the lab using our credentials, we will first notice an area where we can alter our email address.
Step 2:
After that, we’ll use a random email address in place of our own to try and intercept the request using the burp suite.
Step 3:
The request will then be forwarded to the repeater once we have intercepted it using the burp suite proxy.
Step 4:
We will attempt to modify the POST-based request from the website which requires a CSRF token to a GET-based request.
Step 5:
We will now try to eliminate the CSRF token after switching to a GET-based request, and even after doing so, it still validates and returns 302 found.
Step 6:
We will now construct a Proof of Concept with the auto-submit script option enabled by utilising the engagement tools function, which allows for the generation of CSRF PoC.
Step 7:
Craft the proof of concept, store it on the exploit server in the body area, and deliver the exploit to the target through selecting “Deliver exploit to victim.”
Step 8:
The lab would be solved when providing the exploit to the intended target.
