17370845950

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

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种网络攻击，攻击者诱使用户在已登录的网站上执行非用户本意的操作。避免CSRF攻击的关键在于验证请求的来源，确保请求确实来自用户的合法操作。

解决方案：

CSRF攻击的本质是利用用户在已认证网站的信任关系，冒充用户发起请求。防御CSRF主要有以下几种策略：

1. 同步令牌（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 {
       // 拒绝请求
   }

2. 双重提交 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 {
       // 拒绝请求
   }

3. Referer 检查: 检查HTTP请求头中的

   Referer

   字段，验证请求是否来自受信任的域名。但这种方法并非完全可靠，因为

   Referer

   字段可以被篡改或禁用。
   • 局限性：

     Referer

     头可能因为网络环境、浏览器设置等原因丢失或被篡改，所以不能作为主要的防御手段。

4. 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);

5. 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 防御的安全性。