网络安全 | 深入解析CSRF攻击与防御实战

本文深入剖析了CSRF（跨站请求伪造）攻击的原理及防御措施。CSRF通过诱骗已认证用户执行非预期操作，利用浏览器自动携带认证信息的机制实施攻击。文章通过Java代码示例展示了一个典型的CSRF攻击场景：恶意网站利用GET请求修改用户邮箱。针对CSRF防御，提出了三种核心方案：1）使用Anti-CSRF Token机制；2）利用Spring Security内置的CSRF防护功能；3）配置SameS

Andya_net

768人浏览 · 2025-11-16 15:51:53

Andya_net · 2025-11-16 15:51:53 发布

`关注: CodingTechWork`

引言

Cross-Site Request Forgery（CSRF）是一种冒充用户执行非预期操作的攻击方式，它在OWASP Top 10中曾长期占有一席之地。本文将深入剖析CSRF，并通过Java代码示例，展示如何构建坚固的CSRF防线。

CSRF介绍

CSRF（跨站请求伪造），也被称为“One-Click Attack”或“Session Riding”。它是一种诱骗已认证用户在不知情的情况下，运行一个恶意Web应用程序操作的攻击。
核心危害：攻击者并不能直接窃取你的Cookie或会话数据，而是利用你的浏览器对目标网站的已认证状态，以你的名义执行恶意操作，如修改密码、转账、发布内容等。

CSRF攻击类似的流程

你已登录网上银行（相当于在银行大厅办理业务）。
攻击者给你一个精心设计的链接（相当于递给你一张伪造的“转账授权书”）。
你点击了链接，浏览器自动携带你的登录凭证（Cookie）向银行发起转账请求（相当于你在不知情的情况下签署了授权书）。
银行看到是你的凭证，便执行了操作。

CSRF攻击的原理与产生条件

核心原理

利用浏览器的同源策略不会阻止向目标网站发送请求的机制，并自动携带用户的认证信息（如Session Cookie）。

必要条件

用户已登录目标网站（A站），并且会话（Session）未过期。
用户访问了恶意网站（B站），该网站包含一个自动向A站发起请求的代码。
目标网站（A站）完全依赖Cookie（通常是Session Cookie）来认证用户身份，没有其他机制来验证请求的意图。
请求是可预测的，攻击者能构造出执行特定操作所需的请求参数。

一个CSRF攻击是如何发生的？

假设有一个Java Web应用，提供一个修改用户邮箱的GET接口（注意：使用GET进行状态变更操作本身就是不安全的）。

1. 易受攻击的Java Servlet

// 危险的Servlet：使用GET方法执行敏感操作，且无CSRF防护
@WebServlet("/changeEmail")
public class ChangeEmailServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 1. 从Session中验证用户登录状态
        HttpSession session = request.getSession(false);
        if (session != null && session.getAttribute("user") != null) {
            // 2. 用户已登录，执行修改邮箱操作
            String newEmail = request.getParameter("newEmail");
            User user = (User) session.getAttribute("user");
            userService.updateEmail(user.getId(), newEmail); 
            response.getWriter().write("Email updated successfully!");
        } else {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
        }
    }
}

2. 攻击者构造的恶意页面（malicious-site.com）

<!DOCTYPE html>
<html>
<head>
    <title>看起来无害的页面</title>
</head>
<body>
    <h1>来看一张有趣的图片！</h1>
    <!-- 利用img标签的src属性自动发起GET请求 -->
    <img src="http://your-java-app.com/changeEmail?newEmail=hacker@evil.com" 
         width="0" height="0" alt="Fake Image" />
    <p>（实际上，页面在后台悄悄修改了你在“your-java-app.com”的邮箱）</p>

    <script>
        // 或者使用JavaScript自动提交一个隐藏的表单（对POST请求同样有效）
        setTimeout(function() {
            document.getElementById('csrf-form').submit();
        }, 100);
    </script>

    <!-- 隐藏的表单，用于模拟POST请求 -->
    <form id="csrf-form" action="http://your-java-app.com/changeEmail" method="POST" style="display:none;">
        <input type="hidden" name="newEmail" value="hacker@evil.com" />
    </form>
</body>
</html>

攻击流程：

用户登录了 http://your-java-app.com，Session有效。
用户随后访问了 http://malicious-site.com。
恶意页面中的 <img> 标签或JavaScript会自动向 your-java-app.com 发起请求（携带用户的Session Cookie）。
你的Java应用收到请求，验证Session有效，于是执行了修改邮箱的操作。

如何在Java世界中防御CSRF？

防御CSRF的核心思想是：增加一个攻击者无法预测且无法伪造的额外验证凭证。

1. 使用Anti-CSRF Token（同步器令牌模式）

原理：在用户会话中存储一个随机、不可预测的Token（令牌）。在渲染表单时，将此Token作为一个隐藏字段放入表单。当表单提交时，服务器验证提交的Token是否与会话中存储的Token一致。

2. 使用Spring Security

如果你使用Spring框架，Spring Security默认就提供了强大且开箱即用的CSRF防护。

默认行为：Spring Security会为每个Session生成一个CSRF Token，并期望在所有非GET、HEAD、TRACE、OPTIONS的请求（如POST, PUT, PATCH, DELETE）中携带一个名为_csrf的参数或X-CSRF-TOKEN头。

与Thymeleaf集成：在Thymeleaf模板中，只需在表单中添加th:action，Thymeleaf会自动帮你插入CSRF Token隐藏域。

<form th:action="@{/changeEmail}" method="post">
    <input type="email" name="newEmail">
    <button type="submit">更新邮箱</button>
    <!-- Thymeleaf会自动生成：<input type="hidden" name="_csrf" value="..."> -->
</form>

自定义与禁用：如果需要为某些接口（如API）禁用CSRF，可以在配置中操作

@Configuration
@EnableWebSecurity
public class WebSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authz -> authz
                .anyRequest().authenticated()
            )
            .csrf(csrf -> csrf
                // 忽略某些API路径，例如/webhook（风险自担）
                // .ignoringRequestMatchers("/webhook/**")
            );
        return http.build();
    }
}

3. 验证SameSite Cookie

为Cookie设置SameSite属性可以作为一种有效的深度防御措施。

SameSite=Strict：最严格，完全禁止第三方Cookie。
SameSite=Lax：（默认值）在大多数跨站导航（如从外站链接点击过来）时发送Cookie，但不会在跨站的POST请求或图像加载中发送。
SameSite=None：允许跨站发送，但必须同时设置Secure属性（HTTPS）。

在web.xml或Servlet中配置：

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <!-- 仅HTTPS -->
        <secure>true</secure> 
         <!-- 或 strict -->
        <same-site>lax</same-site>
    </cookie-config>
</session-config>