CSRF Cross-Site Request Forgery Attack and Protection

CSRF Cross-Site Request Forgery Attack and Protection

Description
CSRF (Cross-Site Request Forgery) is a malicious attack method where attackers trick users into performing unintended actions (such as modifying passwords, transferring funds, etc.) while they are logged into a target website. Its core lies in exploiting the automatic carrying mechanism of user authentication credentials (such as Cookies) to perform malicious actions through forged requests.

Attack Principle

  1. User Logs into Trusted Website (e.g., Bank Website): The server returns an authentication Cookie, which the browser automatically saves and carries in subsequent requests.
  2. User Visits Malicious Page: The attacker induces the user to visit a page containing malicious code via email or forums.
  3. Forged Request Automatically Triggered: The malicious page hides a forged request (e.g., <img src="http://bank.com/transfer?to=attacker&amount=1000">), and the browser automatically sends the request with the Cookie.
  4. Server Mistakenly Treats It as Legitimate User Action: Because the request contains a valid Cookie, the server executes the action (e.g., transfers funds).

Protection Measures

  1. Same-Origin Policy (SOP) Limitations: Browsers by default prohibit cross-origin reading of responses, but cross-origin requests can still be sent (via tags like <img>, <form>), so SOP cannot fully prevent CSRF.

  2. CSRF Token Verification

    • Principle: Include a random Token (stored in Session or Cookie) in critical requests (e.g., POST), and verify its legitimacy on the server side.
    • Implementation Steps:
      • When a user visits a page, the server generates a random Token and stores it in the Session, while also passing it to the frontend (e.g., as a hidden form field).
      • The frontend includes the Token when submitting requests (e.g., as a form field or request header).
      • The server compares the Token in the request with the one stored in the Session.
    • Key Points: The Token must be random and confidential, making it unpredictable or stealable by attackers (due to Same-Origin Policy restrictions).

  3. SameSite Cookie Attribute

    • Principle: Set the SameSite attribute of Cookies to restrict cross-origin request carrying of Cookies.
      • Strict: Completely prohibits cross-origin carrying of Cookies (may cause user experience issues).
      • Lax (default): Allows some safe requests (e.g., GET) to carry Cookies while blocking unsafe requests (e.g., POST).
    • Example: Set-Cookie: sessionId=abc; SameSite=Lax;

  4. Verify Referer/Origin Headers

    • Check whether the Referer or Origin field in the request header originates from a trusted domain.
    • Limitations: In some scenarios, Referer may be filtered by privacy settings or forged.

  5. Secondary Verification

    • Require users to re-enter passwords or SMS verification codes for sensitive operations (e.g., fund transfers).

Summary
CSRF protection requires combining multiple measures: prioritize using CSRF Tokens (for critical operations) and SameSite Cookies (to reduce reliance on Tokens in some scenarios), supplemented by other verification methods. Understanding the browser's automatic Cookie-carrying mechanism is key to defense.