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会在导航到同一站点的请求中发送，例如点击链接或提交表单。
如知AI笔记
如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型
27 查看详情
优点： 简单易用，可以有效地防御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
头部，例如：用户直接在地址栏输入 URL。从 HTTPS 站点跳转到 HTTP 站点。使用
标签的
rel="noreferrer"
属性。使用某些浏览器插件或安全设置。如果服务端仅仅依赖
Referer
头部进行 CSRF 防御，那么在
Referer
头部丢失的情况下，所有请求都会被拒绝，导致正常用户也无法使用服务。子域名问题： 如果站点存在多个子域名，而服务端只验证主域名，那么攻击者可以通过控制一个子域名来绕过
Referer
检查。例如，如果服务端只验证
example.com
，而攻击者控制了
evil.example.com
，那么攻击者就可以从
evil.example.com
发起 CSRF 攻击。
因此，
Referer
检查只能作为一种辅助的 CSRF 防御手段，不能完全依赖它。更可靠的防御方法包括使用同步令牌（STP）、双重提交 Cookie 以及
SameSite
Cookie 等。
如何选择合适的 CSRF 防御策略？
选择合适的 CSRF 防御策略需要综合考虑以下因素：
安全性要求： 对于安全性要求较高的应用，建议使用同步令牌（STP）或双重提交 Cookie。这两种方法都比较可靠，可以有效地防御 CSRF 攻击。浏览器兼容性： 如果需要兼容旧版本的浏览器，建议使用同步令牌（STP）或双重提交 Cookie。
SameSite
Cookie 需要浏览器支持，旧版本的浏览器可能不支持。开发成本： 同步令牌（STP）需要服务器端生成和验证令牌，开发成本相对较高。双重提交 Cookie 的开发成本相对较低，但需要注意 XSS 攻击的风险。性能影响： 同步令牌（STP）需要在服务器端存储令牌，可能会对性能产生一定影响。双重提交 Cookie 不需要服务器端存储令牌，性能影响较小。
一般来说，同步令牌（STP）是最常用的 CSRF 防御策略。如果对浏览器兼容性有较高要求，或者开发成本有限，可以考虑使用双重提交 Cookie。
SameSite
Cookie 可以作为一种辅助的防御手段，可以有效地防御简单的 CSRF 攻击。
最终选择哪种策略，需要根据具体的应用场景和需求进行权衡。建议采用多种防御手段相结合的方式，以提高 CSRF 防御的安全性。
以上就是什么是 CSRF攻击，如何避免？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/595197.html
微信扫一扫 
支付宝扫一扫 
