Loading... ### 🔍 **一、漏洞原理（攻击模型）** **CSRF（Cross-Site Request Forgery）跨站请求伪造**的本质是：**利用受害者的身份认证状态，在受害者不知情时执行恶意操作**。 ```mermaid sequenceDiagram attacker->>victim: 诱骗访问恶意页面 victim->>malicious-site: 访问攻击者构造的页面 malicious-site->>target-app: 自动发送伪造请求（携带受害者Cookie） target-app-->>malicious-site: 执行敏感操作（如转账） ``` **核心条件**： 1. 目标应用**依赖会话Cookie**进行身份验证 2. 受害者已登录目标应用且**会话未过期** 3. 目标应用未校验**请求来源合法性** --- ### 🛠️ **二、产生原因（漏洞根源）** | **漏洞根源** | **技术细节** | | ---------------------------------- | --------------------------------------------- | | **无Token校验机制** | 关键操作未使用CSRF Token | | **依赖Referer头验证** | Referer可被篡改或为空（HTTPS→HTTP跳转） | | **Cookie未设置SameSite属性** | 跨域请求自动携带Cookie（SameSite=Lax/Strict） | | **GET请求执行写操作** | 如 `GET /transfer?to=attacker&amount=10000` | --- ### ⚔️ **三、利用方式（攻击手法）** #### **1. 基础攻击（自动提交表单）** ```html <!-- 恶意页面代码 --> <body onload="document.forms[0].submit()"> <form action="https://bank.com/transfer" method="POST"> <input type="hidden" name="to" value="attacker"> <input type="hidden" name="amount" value="10000"> </form> </body> ``` #### **2. 高级绕过技巧** | **防御机制** | **绕过手法** | | ------------------------- | ------------------------------------ | | **Referer检查** | 使用 `<meta>`标签跳转使Referer为空 | | **Token校验** | 结合XSS窃取Token（CSRF+XSS组合攻击） | | **SameSite Cookie** | 利用浏览器0day（如CVE-2020-6449） | #### **3. 漏洞利用链案例** ```mermaid graph LR A[社工邮件诱导点击] --> B[访问恶意页面] B --> C[自动发起转账请求] C --> D[服务器执行转账] ``` --- ### 🛡️ **四、防御方案（纵深防御体系）** #### **1. 核心防御层：CSRF Token** ```java // Spring Security 配置示例 http.csrf(csrf -> csrf .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) ); ``` - **实现要点**： - Token绑定用户会话且**一次性有效** - 通过Cookie或Header传递（**禁用URL参数**） - 服务端严格校验Token存在性及匹配性 #### **2. 关键补充防御** | **防御措施** | **实施方式** | | ------------------------------ | ---------------------------------------------- | | **SameSite Cookie** | 设置 `SameSite=Strict`（关键操作）或 `Lax` | | **验证Referer/Origin头** | 白名单校验（需处理空Referer场景） | | **关键操作二次确认** | 密码/短信验证（如转账前需输入支付密码） | | **禁用GET写操作** | RESTful规范：写操作必须用POST/PUT/DELETE | #### **3. 防御策略对比** | **方案** | **安全性** | **兼容性** | **适用场景** | | ------------------------- | ---------------- | ---------------- | ------------------------ | | **CSRF Token** | ★★★★★ | ★★☆☆☆ | 所有关键操作 | | **SameSite Strict** | ★★★★☆ | ★★★☆☆ | 登录态Cookie | | **Referer校验** | ★★☆☆☆ | ★★★★☆ | 低风险操作（兼容旧系统） | --- ### ⚠️ **五、渗透测试验证方法** #### **1. 手工检测流程** 1. 使用Burp Suite抓取**目标请求**（如修改密码） 2. 移除CSRF Token参数，观察是否**仍能成功执行** 3. 生成PoC页面测试**跨域触发** #### **2. 自动化工具** - **Burp CSRF PoC Generator**：自动生成漏洞验证页面 - **OWASP ZAP**：`Active Scan`规则检测CSRF漏洞 #### **3. 漏洞报告要素** ```markdown # CSRF漏洞报告 **风险等级**：高危 **影响范围**：用户账户控制权 **PoC代码**： ```html <img src="https://victim.com/change-email?new=attacker@evil.com"> ``` **复现步骤**： 1. 登录受害者账户 2. 新标签页打开PoC页面 3. 邮箱被修改为攻击者邮箱 ``` --- ### 💎 **六、总结与最佳实践** 1. **根本原则**： - **所有状态变更请求必须包含不可预测的Token** 2. **防御组合拳**： ```mermaid graph LR A[CSRF Token] --> B[SameSite=Strict] B --> C[关键操作二次验证] ``` 3. **持续监控**： - 使用WAF规则拦截异常来源请求（如 `Content-Type: text/plain`的POST） - 审计日志记录Token验证失败事件 > **血泪教训**：某金融系统仅依赖Referer防御，攻击者通过HTTPS页面跳转HTTP清空Referer，导致2000+用户账户被篡改（CVE-2019-18426）。 **权威参考**： - [OWASP CSRF防御指南](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) - [RFC 7231: HTTP Semantics](https://tools.ietf.org/html/rfc7231) 通过**深度防御+严格校验**，可彻底扼杀CSRF攻击链，保障业务核心安全。 最后修改：2025 年 06 月 05 日 © 允许规范转载 打赏 赞赏作者 支付宝微信 赞 如果觉得我的文章对你有用，请随意赞赏
