Cross-Site Request Forgery (CSRF) Attack Explained

Cross-Site Request Forgery (CSRF) Attack Explained

1. Problem Description

Cross-Site Request Forgery (CSRF) is an attack technique where an attacker tricks a logged-in user into performing unintended actions (such as changing a password, transferring funds, etc.) without their knowledge. Its core principle is exploiting the characteristic that a user's logged-in session credentials (e.g., cookies) are automatically included in requests, triggering the target website's business logic through forged requests.

2. Prerequisites for a CSRF Attack

  1. The user is logged into the target website: Session credentials (e.g., session cookies) are valid.
  2. The user visits a malicious page: The attacker induces the user to click a link or visit a page containing malicious code.
  3. The target website has no CSRF protection measures in place: Requests lack a non-forgeable verification mechanism.

3. Example Attack Scenario

Assume a banking website supports password changes via a GET request:

GET http://bank.com/change-password?newpass=123456

The attacker embeds a hidden image request into a malicious page:

<img src="http://bank.com/change-password?newpass=hacked" />

When the user visits this page, the browser automatically sends the request with the logged-in cookie, silently changing the password.

4. Complete CSRF Attack Process

  1. User logs into the banking website: The browser saves the session cookie.
  2. User is tricked into visiting a malicious website (e.g., via a phishing email).
  3. Malicious website contains a forged request: This could be an auto-submitted form, an image link, or an AJAX request initiated by JavaScript.
  4. Browser automatically attaches the cookie: Sends the request to the banking website, and the server mistakenly treats it as a legitimate user action.
  5. Attack completed: Actions like password change or fund transfer are executed.

5. Detailed Defense Measures

(1) Limitations of the Same-Origin Policy (SOP)

Browsers prohibit cross-origin reading of response content, but allow sending cross-origin requests (e.g., form submissions, image loading). Therefore, SOP cannot prevent CSRF.

(2) CSRF Token Verification

  • Principle: Add a randomly generated token (stored on the server or in the session) to forms or request parameters. The server verifies the token's validity.
  • Example: 
    <form action="/change-password" method="POST">
  <input type="hidden" name="csrf_token" value="random_string"/>
  <!-- Other form fields -->
</form>
  • Key Points: The token must be bound to the user session, and attackers cannot obtain it via cross-origin requests (due to SOP restrictions).

(3) SameSite Cookie Attribute

  • Principle: Set the cookie's SameSite attribute to Strict or Lax to restrict automatic cookie inclusion in cross-origin requests.
    • Strict: Completely prohibits cross-site cookie inclusion.
    • Lax: Allows some safe requests (e.g., GET navigation) to include cookies but blocks unsafe requests like POST.

(4) Verifying Request Origin (Referer/Origin Headers)

  • Check whether the Referer or Origin header comes from a legitimate domain. However, this may be disabled by certain browsers or plugins.

(5) Secondary Verification

  • Require users to re-enter their password or perform two-factor authentication for sensitive operations.

6. Summary

CSRF attacks rely on the browser's mechanism of automatically sending credentials. Defense must focus on making requests non-forgeable (e.g., using tokens) or restricting credential sending (e.g., using SameSite cookies). In practice, it is recommended to combine multiple measures (e.g., Token + SameSite) and avoid using GET requests for sensitive operations.