Detailed Explanation of Cross-Site Request Forgery (CSRF) Attack

Detailed Explanation of Cross-Site Request Forgery (CSRF) Attack

1. Knowledge Point Description
Cross-Site Request Forgery (CSRF) is a type of malicious attack. Attackers trick users into performing unintended operations on a web application where they are currently logged in. For example, after logging into a banking website, if a user visits a malicious link without logging out, that link might automatically initiate a transfer request, and the browser will complete the operation using the user's login credentials (such as cookies). The essence of CSRF is exploiting the victim's authentication state to execute unauthorized requests in the user's name.

2. Necessary Conditions for CSRF Attack

  • The user is logged into the target website (e.g., bank, social platform), and the session is still active.
  • The user visits a malicious page crafted by the attacker (e.g., a link in a phishing email).
  • The target website lacks effective CSRF protection mechanisms.

3. Step-by-Step Attack Principle Analysis
Step 1: User Logs into a Trusted Website
The user logs into example-bank.com via the browser. The server returns a cookie containing a session ID, which the browser stores.

Step 2: Luring the User to Visit a Malicious Page
The attacker crafts a hidden request and lures the user to visit it (e.g., via an email or link embedded in a forum):

<!-- Malicious page content -->
<img src="http://example-bank.com/transfer?to=attacker&amount=1000" width="0" height="0">

When the user visits this page, the browser automatically sends a GET request, carrying the stored cookie.

Step 3: Server Mistakenly Treats the Request as a Voluntary User Action
The server verifies the cookie is valid and executes the transfer operation, completing the attack.

Example of a More Concealed POST Request:

<form id="csrf-form" action="http://example-bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="1000">
</form>
<script>document.getElementById('csrf-form').submit();</script>

4. Detailed Defense Measures
(1) Limitations of the Same-Origin Policy (SOP)
The Same-Origin Policy prevents reading cross-origin responses but does not prevent sending cross-origin requests. Therefore, malicious pages can still initiate requests (e.g., form submissions), and the server may still process them.

(2) CSRF Token Mechanism

  • The server generates a random Token for each session and embeds it in forms or request headers: 
    <form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="random_string">
  <!-- Other fields -->
</form>
  • When the request is submitted, the server verifies if the Token matches. Malicious pages cannot obtain this Token (restricted by SOP).

(3) SameSite Cookie Attribute
Set the SameSite attribute for cookies to restrict cross-site cookie carrying:

  • Strict: Completely prohibits cross-site cookie carrying (may affect user experience).
  • Lax: Allows certain safe requests (e.g., GET) to carry cookies while blocking non-safe requests (e.g., POST).

(4) Verifying Request Origin (Referer/Origin Headers)
The server checks the Referer or Origin fields in the HTTP headers to ensure the request originates from the same domain. However, it must handle cases where the Referer is missing (e.g., in private browsing mode).

(5) Secondary Confirmation for Critical Operations
For sensitive operations (e.g., fund transfers), require users to re-enter their password or a verification code.

5. Practical Scenario Examples

  • Defense Configuration Example (SameSite Cookie):
    Server sets the cookie: Set-Cookie: sessionid=abc123; SameSite=Lax; HttpOnly
  • Token Verification Process:
    When a user visits a page, the server dynamically generates a Token and embeds it in the form. Upon submission, the server compares it with the stored Token.

6. Summary
CSRF attacks exploit the browser's default cookie-carrying mechanism. The core of defense is ensuring that requests come from legitimate sources. Combining Tokens, SameSite Cookies, and origin verification can effectively protect against such attacks.