CSRF
Cross Site Request Forgery
Last updated
Cross Site Request Forgery
Last updated
A relevant action. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password)
Cookie-based session handling.
No unpredictable request parameters. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.
Create an account as an attacker and fill all the form, check your info in the Account Detail.
Change the email and capture the request, then created a CSRF Exploit.
CSRF POST PoC
GET request PoC:
Also try with "Reset Password"
right-click context menu, select Engagement tools / Generate CSRF PoC.
Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.
Switch to the GET method to bypass the validation and deliver a CSRF attack
Some applications correctly validate the token when it is present but skip the validation if the token is omitted.
Try to send csrftoken=null or csrftoken=%00
Also try to fuzz from %00 to %ff
Some applications do not validate that the token belongs to the same session as the user who is making the request
Log in to the application using your own account, obtain a valid token, and then feed that token to the victim user in your CSRF attack
Log in to the application using your own account, obtain a valid token and associated cookie, leverage the cookie-setting behavior to place your cookie into the victim's browser, and feed your token to the victim in your CSRF attack.
Create a URL that uses this vulnerability to inject your csrfKey cookie into the victim's browser:
Create a PoC, ensuring that you include your CSRF token. Remove the auto-submit <script> block, and instead add the following code to inject the cookie
The application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie.
Invent a token (perhaps in the required format, if that is being checked), leverage the cookie-setting behavior to place your cookie into the victim's browser, and feed your token to the victim in your CSRF attack.
Create a URL that uses this vulnerability to inject your csrfKey cookie into the victim's browser:
Create a PoC, ensuring that you include your CSRF token. Remove the auto-submit <script> block, and instead add the following code to inject the cookie
If they also use Lax restrictions for their session cookies, either explicitly or due to the browser default, you may still be able to perform a CSRF attack by eliciting a GET request from the victim's browser.
Try overriding the method by adding the _method parameter to the query string:
Look for a gadget that results in a secondary request within the same site.
One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters
Drop the referer header in your poc. Include the following code in your PoC:
Alter the referer URL
Make sure that the Referrer-Policy: unsafe-url header is set. This ensures that the full URL will be sent, including the query string.
Edit the PoC JavaScript so that the third argument of the history.pushState() function includes a query string with your lab instance URL as follows:
history.pushState("", "", "/?vulnerable.net")
This will cause the Referer header in the generated request to contain the URL of the target site in the query string, just like we tested earlier.
I hope it helps you as much as it has helped me. If you can support me in any way, I would deeply appreciate it.
The go-to manual for web app pentesters. Covers XSS, SQLi, logic flaws, and more
Learn how to perform reconnaissance on a target, how to identify vulnerabilities, and how to exploit them
Learn about the most common types of bugs like cross-site scripting, insecure direct object references, and server-side request forgery.
