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

星降

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

341人浏览过

来源于php中文网

原创

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("");

// 验证 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会在导航到同一站点的请求中发送，例如点击链接或提交表单。

Transor
专业的AI翻译工具，支持网页、字幕、PDF、图片实时翻译

下载
- 优点： 简单易用，可以有效地防御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

检查。例如，如果服务端只验证

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。