Detailed Explanation of CSRF (Cross-Site Request Forgery) Attacks
Description
CSRF (Cross-Site Request Forgery) is an attack that maliciously exploits a website's authentication mechanism. The attacker tricks a logged-in user into unknowingly submitting malicious requests (such as transferring money or changing passwords) to a trusted website during an active session. Its core lies in exploiting the browser's feature of automatically carrying cookies, causing the user to "be represented" in performing unintended operations.
Step-by-Step Analysis of Attack Principles
- Authentication Dependency: After a user logs into Website A, the session cookie returned by the server is automatically stored by the browser and attached to subsequent requests.
- Session Persistence Vulnerability: As long as the user has not logged out or the session has not expired, any request initiated by the browser to Website A will carry the valid cookie.
- Forged Request Construction: Attackers create hidden forms, malicious image links, etc., containing key parameters for modifying data (e.g.,
transfer?to=attacker&amount=1000). - Luring Trigger: The user is tricked into visiting a malicious page through channels such as email or forums. The browser automatically executes the request and carries the legitimate cookie, causing the server to mistakenly interpret it as a voluntary action by the user.
Typical Attack Scenario Example
Assume the bank website's transfer interface is:
POST /transfer HTTP/1.1
Cookie: session=user_session_id
Content-Type: application/x-www-form-urlencoded
to_account=ATTACKER&amount=10000
The attacker constructs a malicious page:
<img src="http://bank.com/transfer?to_account=ATTACKER&amount=10000" />
<!-- Or hidden form -->
<body onload="document.forms[0].submit()">
<form action="http://bank.com/transfer" method="POST">
<input type="hidden" name="to_account" value="ATTACKER">
<input type="hidden" name="amount" value="10000">
</form>
</body>
Layered Detailed Explanation of Defense Measures
- Same-Origin Policy Check: The server validates the Origin/Referer fields in the HTTP request headers to ensure the request source matches the target domain.
- CSRF Token Protection:
- The server generates a random Token (e.g.,
csrftoken=abc123), stores it in the session, and embeds it into the form (or Meta tag). - When submitting a request, the Token must be carried, and the server verifies whether it matches the one stored in the session.
- Key: The Token must be randomized, bound to the session, and updated each time (important operations require refresh).
- The server generates a random Token (e.g.,
- Double Cookie Verification: Attach the value from the cookie as a parameter to the request, and the server compares whether the cookie value matches the parameter value.
- Critical Operation Reinforcement:
- Sensitive operations require secondary authentication (password, SMS verification code).
- Use custom headers (requires CORS configuration).
- Browser Protection:
- SameSite Cookie attribute (Strict/Lax restricts third-party cookie carrying).
- Use JSON API for critical interfaces and avoid modifying data with GET requests.
Advanced Defense Strategies
- User Interaction Verification: Add sliding CAPTCHA/behavioral CAPTCHA to increase the cost of attacks.
- Request Fingerprint Verification: Combine User-Agent, IP address, etc., to generate a request fingerprint.
- Critical Operation Logging: Record operation IP, time, device information for anomaly traceability.
By combining defense strategies (such as Token + SameSite Cookie), the CSRF attack chain can be effectively blocked. The core lies in ensuring the "authenticity" of the request, not just its "legitimacy."