CSRF攻击通过伪造用户请求执行非授权操作，防御核心是验证请求来源。主要策略包括：同步令牌模式（STP），在表单中嵌入服务器生成的随机令牌并验证；双重提交Cookie，将令牌同时存于Cookie和请求参数并比对；SameSite Cookie，设置Cookie的SameSite属性为Strict或Lax以限制跨站发送；Referer和Origin检查，验证请求来源域名，但前者易被篡改或缺失，后者更可靠但兼容性有限。其中STP最常用且安全，适合高安全需求场景；双重提交Cookie开发成本低但需防XSS；SameSite简单有效但依赖浏览器支持。建议结合多种方法提升防护能力。
CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种网络攻击，攻击者诱使用户在已登录的网站上执行非用户本意的操作。避免CSRF攻击的关键在于验证请求的来源，确保请求确实来自用户的合法操作。
解决方案：
CSRF攻击的本质是利用用户在已认证网站的信任关系，冒充用户发起请求。防御CSRF主要有以下几种策略：
-
同步令牌（Synchronizer Token Pattern，STP）: 这是最常见的防御方法。服务器在用户访问页面时生成一个随机的、唯一的CSRF令牌，并将它嵌入到表单或链接中。当用户提交表单或点击链接时，浏览器会将这个令牌一起发送给服务器。服务器验证令牌是否与用户会话中存储的令牌匹配。如果匹配，则认为请求是合法的；否则，拒绝请求。
-
实现细节：
- 在用户登录后，服务器生成一个随机字符串，例如使用
UUID.randomUUID().toString()
。 - 将该字符串存储在用户的session中，同时将其作为隐藏字段添加到所有需要CSRF保护的表单中。
- 当用户提交表单时，服务器比较表单中的CSRF令牌和session中的CSRF令牌。
- 如果令牌匹配，则处理请求；否则，拒绝请求并返回错误信息。
- 在用户登录后，服务器生成一个随机字符串，例如使用
代码示例 (Java):
// 生成 CSRF 令牌 String csrfToken = UUID.randomUUID().toString(); request.getSession().setAttribute("csrfToken", csrfToken); // 在表单中添加 CSRF 令牌 out.println(""); // 验证 CSRF 令牌 String sessionToken = (String) request.getSession().getAttribute("csrfToken"); String requestToken = request.getParameter("csrfToken"); if (sessionToken != null && sessionToken.equals(requestToken)) { // 处理请求 } else { // 拒绝请求 } -
-
双重提交 Cookie（Double Submit Cookie）: 服务器不存储CSRF令牌，而是将令牌同时设置在Cookie和请求参数中。服务器验证Cookie中的令牌和请求参数中的令牌是否一致。因为只有来自同一域的脚本才能读取Cookie，所以可以防止跨域攻击。
-
实现细节：
- 服务器生成一个随机字符串。
- 将该字符串设置为一个HTTP Cookie。
- 同时，将该字符串作为请求参数（例如，隐藏的表单字段）添加到所有需要CSRF保护的表单中。
- 当用户提交表单时，服务器比较Cookie中的CSRF令牌和请求参数中的CSRF令牌。
- 如果令牌匹配，则处理请求；否则，拒绝请求并返回错误信息。
代码示例 (JavaScript & Server-side):
// JavaScript (设置 Cookie) function setCookie(name, value, days) { // ... (Cookie 设置逻辑) } let csrfToken = generateRandomToken(); // 假设有这个函数生成随机令牌 setCookie('csrfToken', csrfToken, 7); // 设置 7 天过期 document.getElementById('csrf_token').value = csrfToken; // 设置隐藏字段// Java (验证 Cookie) Cookie[] cookies = request.getCookies(); String cookieToken = null; if (cookies != null) { for (Cookie cookie : cookies) { if (cookie.getName().equals("csrfToken")) { cookieToken = cookie.getValue(); break; } } } String requestToken = request.getParameter("csrfToken"); if (cookieToken != null && cookieToken.equals(requestToken)) { // 处理请求 } else { // 拒绝请求 } -
-
Referer 检查: 检查HTTP请求头中的
Referer
字段，验证请求是否来自受信任的域名。但这种方法并非完全可靠，因为Referer
字段可以被篡改或禁用。-
局限性：
Referer
头可能因为网络环境、浏览器设置等原因丢失或被篡改，所以不能作为主要的防御手段。
-
局限性：
-
SameSite Cookie: 设置Cookie的
SameSite
属性为Strict
或Lax
。Strict
模式下，Cookie只会在同一站点发起的请求中发送。Lax
模式下，Cookie会在导航到同一站点的请求中发送，例如点击链接或提交表单。优点： 简单易用，可以有效地防御CSRF攻击。
缺点： 需要浏览器支持，旧版本的浏览器可能不支持
SameSite
属性。代码示例 (Java):
Cookie csrfCookie = new Cookie("csrfToken", csrfToken); csrfCookie.setHttpOnly(true); csrfCookie.setSecure(true); // 建议在 HTTPS 环境下使用 csrfCookie.setPath("/"); csrfCookie.setSameSite("Strict"); // 或者 "Lax" response.addCookie(csrfCookie); -
Origin 检查: 检查HTTP请求头中的
Origin
字段，验证请求的来源。Origin
字段比Referer
字段更可靠，因为它是由浏览器设置的，无法被篡改。但是，并非所有浏览器都支持Origin
字段。-
局限性： 并非所有浏览器都支持
Origin
头。对于不支持Origin
头的浏览器，可以考虑结合Referer
头进行检查，但仍然需要注意Referer
头的可篡改性。
-
局限性： 并非所有浏览器都支持
为什么 Referer 检查不能完全防御 CSRF？
Referer头部字段包含了发起 HTTP 请求的来源地址。理论上，服务端可以通过检查
Referer来判断请求是否来自合法的页面。然而，
Referer检查存在以下缺陷，导致其无法完全防御 CSRF 攻击：
-
Referer
头部可以被篡改： 尽管浏览器会默认设置Referer
头部，但用户可以通过浏览器插件或者配置来修改甚至禁用Referer
头部。攻击者可以利用这一点，伪造Referer
头部，绕过服务端的检查。 -
某些情况下
Referer
头部会丢失： 在某些情况下，浏览器可能不会发送Referer
头部，例如： -
子域名问题： 如果站点存在多个子域名，而服务端只验证主域名，那么攻击者可以通过控制一个子域名来绕过
Referer
检查。例如，如果服务端只验证example.com
，而攻击者控制了evil.example.com
，那么攻击者就可以从evil.example.com
发起 CSRF 攻击。
因此，
Referer检查只能作为一种辅助的 CSRF 防御手段，不能完全依赖它。更可靠的防御方法包括使用同步令牌（STP）、双重提交 Cookie 以及
SameSiteCookie 等。
如何选择合适的 CSRF 防御策略？
选择合适的 CSRF 防御策略需要综合考虑以下因素：
- 安全性要求： 对于安全性要求较高的应用，建议使用同步令牌（STP）或双重提交 Cookie。这两种方法都比较可靠，可以有效地防御 CSRF 攻击。
-
浏览器兼容性： 如果需要兼容旧版本的浏览器，建议使用同步令牌（STP）或双重提交 Cookie。
SameSite
Cookie 需要浏览器支持，旧版本的浏览器可能不支持。 - 开发成本： 同步令牌（STP）需要服务器端生成和验证令牌，开发成本相对较高。双重提交 Cookie 的开发成本相对较低，但需要注意 XSS 攻击的风险。
- 性能影响： 同步令牌（STP）需要在服务器端存储令牌，可能会对性能产生一定影响。双重提交 Cookie 不需要服务器端存储令牌，性能影响较小。
一般来说，同步令牌（STP）是最常用的 CSRF 防御策略。如果对浏览器兼容性有较高要求，或者开发成本有限，可以考虑使用双重提交 Cookie。
SameSiteCookie 可以作为一种辅助的防御手段，可以有效地防御简单的 CSRF 攻击。
最终选择哪种策略，需要根据具体的应用场景和需求进行权衡。建议采用多种防御手段相结合的方式，以提高 CSRF 防御的安全性。
