How does CSRF attack work?

Great question! Understanding how CSRF attacks work is crucial for both attacking and defending web applications.

Here's a breakdown of how a Cross-Site Request Forgery (CSRF) attack typically works:

The Goal:
The attacker's goal is to trick an already authenticated user into unknowingly performing an action on a legitimate web application that the user didn't intend to do. This action could be anything from changing their email address, transferring funds, making a purchase, to even changing their password.

Key Components for a CSRF Attack:

1. Authenticated User: The user must be logged into the target website (e.g., their bank, social media, or online store). This is because the attack relies on the browser automatically sending the user's session cookies along with the malicious request, making the request appear legitimate to the target website.
2. Trusted Website: The target website must process requests that perform state-changing actions (like changing email, placing an order, etc.) without sufficiently verifying that the request originated from a legitimate source.
3. Malicious Website/Content: The attacker creates a malicious webpage, email, or other content that contains a crafted request designed to perform the unwanted action on the trusted website.

Step-by-Step Scenario:

1. User Logs In: A user (Alice) logs into a legitimate website, let's say her banking website (bank.example.com). When she logs in, her browser receives a session cookie from bank.example.com. This cookie proves her identity for subsequent requests and is stored in her browser. She remains logged in.

2. Attacker Crafts Malicious Request: An attacker (Mallory) wants Alice to transfer money to Mallory's account without Alice knowing. Mallory knows (or guesses) the URL structure for making a transfer on bank.example.com.
   For example, a legitimate transfer request might look like this:
   POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: sessionid=ABCD123...
Content-Type: application/x-www-form-urlencoded
amount=1000&toAccount=MalloryAccount

   Mallory crafts a request that would perform this action, often embedding it within an HTML tag that automatically triggers a request, like an <img> tag, a hidden form, or a JavaScript-triggered AJAX request.

   • Example using <img> (GET request):
     <img src="http://bank.example.com/transfer?amount=1000&toAccount=MalloryAccount" style="display:none;">
     (Note: <img> tags are often used for simpler GET requests, but hidden forms or JavaScript can target more complex POST requests.)

   • Example using a hidden form (POST request):

     <form action="http://bank.example.com/transfer" method="POST" style="display:none;">
         <input type="hidden" name="amount" value="1000">
         <input type="hidden" name="toAccount" value="MalloryAccount">
         <input type="submit" value="Submit">
     </form>
     <script>document.forms[0].submit();</script>

3. Attacker Lures the User: Mallory then embeds this malicious content (e.g., the <img> tag or the hidden form) into a webpage they control (malicious.example.com), or sends it to Alice via email, instant message, etc.

4. User Visits Malicious Content: Alice (who is still logged into bank.example.com in another browser tab or window) is tricked into visiting malicious.example.com (or opening the malicious email).

5. Browser Sends Request: When Alice's browser renders the malicious content, it automatically attempts to load the <img> src or submits the hidden form. Because Alice is still authenticated with bank.example.com, her browser automatically includes her session cookie (sessionid=ABCD123...) with this crafted request.

6. Website Processes Unintended Action: The bank.example.com server receives what appears to be a legitimate request from Alice (because it has her valid session cookie) and processes the transaction – transferring 1000 units of currency to MalloryAccount. Alice is completely unaware that this has happened.

Why it's "Cross-Site": The attack originates from malicious.example.com but forces an action on bank.example.com.

Key Defense (CSRF Tokens):
The most common and effective defense against CSRF is using CSRF tokens. When a user requests a form or performs an action, the server generates a unique, unpredictable token and embeds it as a hidden field in the form or in the request URL. When the user submits the form, the server verifies that the received token matches the one it generated. Since an attacker cannot predict or obtain this token from a different site, their forged request will lack the valid token, and the server will reject it.

I hope this detailed explanation helps you understand how CSRF attacks work! Let me know if you have any more questions.