什么是 CSRF攻击，如何避免？-Java面试题-PHP中文网

什么是 CSRF攻击，如何避免？

星降

发布： 2025-09-02 08:15:01

原创

298人浏览过

CSRF攻击通过伪造用户请求执行非授权操作，防御核心是验证请求来源。主要策略包括：同步令牌模式（STP），在表单中嵌入服务器生成的随机令牌并验证；双重提交Cookie，将令牌同时存于Cookie和请求参数并比对；SameSite Cookie，设置Cookie的SameSite属性为Strict或Lax以限制跨站发送；Referer和Origin检查，验证请求来源域名，但前者易被篡改或缺失，后者更可靠但兼容性有限。其中STP最常用且安全，适合高安全需求场景；双重提交Cookie开发成本低但需防XSS；SameSite简单有效但依赖浏览器支持。建议结合多种方法提升防护能力。

什么是 csrf攻击，如何避免？

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("<input type='hidden' name='csrfToken' value='" + csrfToken + "'>");

// 验证 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 站点。
- 使用
```
<a>
```
  登录后复制
  标签的
```
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。