CSRF漏洞实战指南：从DVWA靶场到短链接与XSS组合利用

1. 一次CSRF的实战触动漏洞往往藏在理所当然里提到Web渗透测试很多人第一反应就是SQL注入、XSS这些明星漏洞CSRFCross-Site Request Forgery跨站请求伪造常常被排在后面。但说实话我在实际授权测试中遇到CSRF的频率比想象中高得多。尤其是那些已经上了WAF、过滤了XSS、加了验证码的站点反而经常在CSRF这条线上暴露出问题——因为开发人员普遍认为只要请求里带了Cookie就是用户本人操作而这个理所当然恰恰是CSRF存在的根基。这篇文章我会结合DVWA靶场把CSRF从原理到实战走一遍内容包括Low/Medium/High三个级别的绕过思路、短链接在攻击链里的作用以及和XSS打组合拳的玩法。适合刚入门Web安全、准备考取相关证书或做渗透测试项目的朋友参考。所有实验均在本地靶场环境完成强调一点任何技术都必须在获得明确授权后才能用于真实目标。2. CSRF的攻击逻辑浏览器帮你完成了合法请求2.1 三个必要条件目标请求、Cookie自动携带、参数可预测CSRF能成立靠的是三个条件同时满足。缺任何一个攻击就失效了。第一攻击目标是一个状态改变型请求比如修改密码、转账、改邮箱、发帖、删好友。GET请求最常见POST也可以但利用起来稍麻烦。第二浏览器在处理跨域资源请求时会自动带上目标站点的Cookie只要没有设置SameSite等限制这正是身份凭证自动随行的机制。第三攻击者能够提前预测或构造出完整的请求参数——如果目标请求里带了随机Token、验证码、二次确认密码就没法直接预测了。这三条听起来简单实际测的时候每一条都可能出现变种。有些系统的改密码功能虽然要求填旧密码但旧密码字段名是固定的攻击者完全可以构造一个表单让受害者提交时自动填上攻击者预设的旧密码——前提是攻击者知道目标当前的密码。所以更多实战里CSRF的目标通常是不需要旧密码的改密接口、绑定手机号接口、添加管理员接口等。2.2 攻击者视角的角色划分从攻击链路看CSRF牵涉三方角色受害者持有目标站点有效会话Cookie的登录用户攻击者构造恶意请求页面的人受害者会在不知情的情况下替攻击者完成操作目标站点提供状态变更接口的Web应用攻击者不需要拿到受害者的Cookie不需要知道受害者的密码甚至不需要和目标站点有正常交互。整个攻击过程里浏览器扮演了被利用的中间人。很多人会把CSRF和XSS搞混。区别很简单XSS利用的是用户对某个站点的信任用户信任的页面里注入了恶意脚本而CSRF利用的是站点对浏览器的信任站点信任浏览器会自动携带有效Cookie。二者可以互相配合后面我会专门展开。2.3 CSRF与点击劫持、SSRF的边界面试和实战里还容易碰到概念混淆。点击劫持是用透明iframe诱导用户点按钮核心是视觉欺骗CSRF是诱导浏览器发送预设请求核心是请求伪造。SSRF则是服务端主动去请求攻击者指定的URL属于服务端请求伪造。三者的攻击入口和影响面完全不同判断漏洞类型时先看谁发的请求浏览器发的就是CSRF/点击劫持服务端发的就是SSRF。3. DVWA靶场实战从Low到High的CSRF绕过全链路3.1 环境搭建与基本配置我用的组合是DVWA 1.9 PHP 7.x Burp Suite Community。如果你是第一次接触DVWA注意两点把DVWA的配置文件config/config.inc.php里的security_level设置为low登录后也可以在DVWA Security页面直接调整级别无需改文件。确保浏览器代理指向Burp127.0.0.1:8080并安装Burp的CA证书否则抓不到HTTPS流量。DVWA的CSRF模块是一个修改密码功能输入新密码两次提交后生效。这个模块设计得很典型——Low级别直接GET提交Medium加了Referer校验High加了不可预测的Token层层递进。3.2 Low级别GET型CSRF直接构造URL把DVWA安全级别切到Low打开CSRF模块Burp里抓到的请求长这样GET /dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange HTTP/1.1 Host: 127.0.0.1 Cookie: PHPSESSIDabcdef1234567890注意几个关键点请求方式是GET参数放在URL里没有Token、没有Referer校验身份凭证只有Cookie里的PHPSESSID这种条件下攻击最简单只要受害者点击一个指向该URL的链接浏览器就会带着Cookie发起GET请求密码直接被改成攻击者指定的值。受害者看到的链接可以伪装成任意形式。比如用短链接服务把完整攻击URL压缩或者用HTML的a标签包裹一段普通文字a hrefhttp://192.168.1.100/dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange点击查看照片/a更隐蔽的方式是放进一个零像素iframe里页面加载时自动触发iframe srchttp://192.168.1.100/dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange styledisplay:none/iframe实测时我在攻击页面上放了两种payload都能在受害者访问后成功篡改密码。Low级别利用难度几乎为零属于任何会写HTML的人都能打的程度。3.3 Medium级别Referer校验与绕过把安全级别切到Medium再试Burp里请求多了一个判断服务端会检查HTTP_REFERER头里是否包含目标站点的域名。看起来安全了不少但开发人员常犯的错误是校验方式写成了包含匹配而不是精确匹配。DVWA Medium级别的代码逻辑是if( stripos( $_SERVER[ HTTP_REFERER ] , $_SERVER[ SERVER_NAME ] ) ) { // 通过校验执行修改密码 }stripos只判断Referer字符串里是否出现过服务器域名不判断位置也不要求前缀匹配。这意味着只要请求的Referer里带有127.0.0.1、localhost或目标站点的实际域名就能通过校验。绕过方法也简单攻击页面自己可以控制Referer。我在自己的VPS上放了一个HTML页面页面里嵌了一个表单提交地址指向DVWA再用JS把页面标题或某个字段设置为http://127.0.0.1浏览器发出POST请求时Referer就会带上这个域名。form actionhttp://192.168.1.100/dvwa/vulnerabilities/csrf/ methodPOST input typehidden namepassword_new valuehacked input typehidden namepassword_conf valuehacked /form script document.forms[0].submit(); /script页面挂在攻击者自己的域名下时Referer默认是攻击者域名但是如果该页面内再放置一个指向目标站点的链接或者直接通过JS修改document.referrer是不行的真正的技巧是让DVWA认为Referer来自它自己——可以用一个同域名下的开放重定向来中转。不过在DVWA本机测试时还有个更简单的路子直接把攻击页面放在DVWA同域下的另一个目录里比如本机web目录下Referer天然就是目标域名。实战中遇到Medium这种包含匹配的校验我会优先测试Referer里加目标域名的路径参数如http://attacker.com/?refhttp://target.com利用目标站点的开放重定向利用同站任意文件上传点放置攻击页面核心思路就是凑齐Referer里的目标域名片段。3.4 High级别Token校验与突破思路High级别的CSRF模块加入了Token校验请求里必须带一个随机的user_token而且在同一会话中这个Token只能用一次。直接构造URL的方式立刻失效因为攻击者无法提前知道受害者当前会话的Token值。但是这里有个经典的突破口DVWA的CSRF模块在生成页面时表单里是直接渲染了当前有效的Token的。也就是说受害者只要打开过修改密码页面页面上就带着Token。攻击者可以构造一个攻击页面用iframe或AJAX先请求目标站点页面并把Token提取出来再自动提交密码修改请求——这个手法就是后面要展开的CSRF与XSS组合利用的雏形。在DVWA High级别下我实际测试时由于页面自带Token动态刷新单纯靠外部页面无法猜到Token所以在不借助XSS的前提下CSRF利用难度确实很高。但这恰恰说明了为什么很多高危组合漏洞都出现在CSRF需要Token但Token能从页面上被XSS读到的场景里。4. 短链接让恶意请求看起来人畜无害4.1 短链接在CSRF里的作用CSRF利用的最大阻碍之一是攻击URL太长、太可疑。http://192.168.1.100/dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange这串东西扔到群里稍微有点安全意识的人都会警惕。短链接服务的价值就在这里——把一长串恶意URL压成十几个字符受害者看到的是一个完全中性的短地址。短链接服务的基本原理是把短码映射到原始URL用户访问短码时服务端返回302跳转。这个跳转过程对CSRF有一个天然的好处浏览器在访问攻击者页面时只要受害者点击短链接它会先请求短链接域名再被302带到目标地址。对于目标站点来说这只是一次普通的浏览器请求只要目标的CSRF校验不看完整跳转链路就识别不出来。4.2 实战里我见过的短链接玩法我在授权测试里见过三种典型的短链接利用场景第一种伪装成福利链接。攻击者把CSRF攻击URL缩短后包装成限时优惠抽奖活动发到群里受害者点击后密码就改了。第二种利用短链接服务自身的域名信誉。一些目标站点做了URL黑名单检测到请求来源域名是恶意域名就拦截。短链接服务域名如一些公开短链平台通常信誉良好能绕过这类基于域名信誉的防护。第三种把短链接嵌进二维码。线下场景里把短链接生成二维码贴到公共场所受害者扫码后自动触发CSRF请求。移动端浏览器一样会自动带Cookie这招在钓鱼场景里效果出奇的好。我自己实际测试时短链接平台通常能正常跳转但个别平台会对目标域名做安全检测发现是IP地址或带明显攻击参数会直接拦截。所以更稳妥的做法是先用一个跳转次数少的短链接或者自己搭一个轻量跳转服务比如用一个闲置域名做302跳转这样既保留了短链接的隐蔽性又避免被平台规则卡住。4.3 短链接与CSRF结合时要注意的坑短链接不是无脑套用有几条测试中总结的经验目标站点若校验Referer的域名短链接跳转过来后Referer通常会变成目标站点自身或留空这反而有利于绕过Medium级别校验。若目标应用只允许同源请求比如校验Origin头短链接跳转后的Origin往往为空或为短链接域名这时利用失败概率很高需要改用同源XSS或存储型XSS来配合。短链接平台如果对目标URL做了302缓存可能会导致目标站点收到多个重复请求CSRF Token一次性校验时会造成误判测试时注意观察响应码。5. 组合拳CSRF配合XSS、存储型XSS的进阶利用5.1 为什么单打独斗打不穿组合起来却可以CSRF最大的盲区是参数不可预测——一旦目标加了Token或SecureToken机制外部攻击者就没了办法。XSS最大的优势恰恰是能读取页面内容、能拿到DOM控制权、能代发请求。两者一结合CSRF的不可预测参数问题被XSS的同源读取能力解决XSS的被动等待受害者操作问题被CSRF的自动请求能力弥补。所以实战里最经典的高危组合就是目标站点某处存在存储型XSS比如评论区、个人签名目标站点某状态变更接口存在CSRF-Token校验但Token可以从页面源码或DOM中读取攻击者把XSS脚本注入到评论区脚本自动执行fetch或XMLHttpRequest读取Token然后带着Token提交修改密码请求5.2 实操演示DVWA存储型XSS CSRF组合以DVWA为例先在XSS Stored模块的Message Board里注入一段脚本。Low级别的存储型XSS不设防脚本可以直接写进消息里script var tokenElement document.querySelector(input[nameuser_token]); if (tokenElement) { var token tokenElement.value; fetch(/dvwa/vulnerabilities/csrf/?password_newcombo123password_confcombo123ChangeChangeuser_token token, { method: GET, credentials: include }); } /script这段脚本做的事情很简单受害者打开留言板页面时脚本先找到当前页面里name为user_token的输入框取出值拼接到CSRF攻击URL上再用fetch携带Cookie发起请求。因为脚本运行在目标站点同源环境下它能拿到Token、能带上会话CSRF防护直接失效。我在DVWA High级别下实际测试过这种组合效果立竿见影——单靠外部CSRF payload打不动High级别但只要先在留言板里埋好这条存储型XSS受害者一访问页面密码就被秒改。这个测试也验证了很多企业站点里单个漏洞可能不致命漏洞组合之后就是RCE级风险的结论。5.3 DOM型XSS与CSRF的另一条组合路径除了存储型XSSDOM型XSS也可以配合CSRF。尤其在一些SPA应用里虽然服务端API有CSRF Token校验但Token被放在了某个可被DOM XSS读取的全局变量里。现实世界中嵌套Web应用前端工程化打包后的JS可能包含大量DOM操作点攻击者只要找到一个可以控制innerHTML或document.write的入口脚本就能循环读取Cookie、Token、LocalStorage等敏感信息配合后端一个存在逻辑缺陷的CSRF接口整套链路就通了。5.4 组合攻击的检测思路作为防御方检测这类组合漏洞时有几条实战经验检查所有XSS注入点是否有同源下的CSRF可利用接口重点关注Token可从DOM读取的接口检查所有状态变更接口是否校验了Origin和Referer的精确匹配检查Cookie是否设置了SameSite属性Lax模式只能阻止部分跨站请求并不能完全防御CSRF用自动化工具做一轮基础CSRF扫描但组合漏洞还是要靠人工探索里外关联工具很难理解业务层面的参数依赖6. 防护方案与验证从开发侧堵住这条路6.1 服务端防御CSRF的四种标准做法CSRF Token每个会话生成随机Token放在表单隐藏域或自定义Header里服务端校验一致性。关键点是Token要足够随机、一次性使用、与Session绑定。推荐用Header方式而不是表单参数Header不会出现在日志里也不容易被Referer泄漏。SameSite CookieCookie加SameSiteLax或Strict属性。Lax模式下跨站POST请求不带Cookie能挡住大部分CSRF但GET型请求在部分浏览器下仍会带Cookie所以不能完全依赖。校验Origin/Referer精确校验请求来源对POST请求优先校验Origin头它能更稳定地反映发起请求的站点。敏感操作二次确认修改密码、解绑手机等高风险操作强制要求输入当前密码或短信验证码。表格对比一下不同防御手段的强度与盲区防御手段拦截强度盲区CSRF TokenHeader高若存在同源XSSToken可被读取失效CSRF Token表单字段中Token可能在页面源码中暴露配合XSS可绕过SameSiteLax中对同站子域、部分浏览器GET请求防护有限SameSiteStrict高影响用户体验部分场景过于严格Origin/Referer精确校验中高浏览器插件、跳转链路异常时可能丢头二次确认密码高体验差但对抗CSRF最直接有效6.2 验证CSRF是否被修复的检查清单修完漏洞之后我都会按这个清单手工复核一遍修改密码、添加管理员、改邮箱三个高风险接口分别用GET和POST尝试外部伪造是否成功不带Origin头、伪造Referer、空Referer三种场景分别测试在同一会话内重复使用Token确认Token是否一次性用Burp的CSRF PoC生成器生成完整攻击页模拟真实浏览器环境验证检查Cookie是否带SameSite属性是否设置Secure标记存储型XSS点是否存在若存在则确认XSS是否可读取Token这是最容易遗漏的一点6.3 框架层防护的坑很多现代化框架如Spring Security、Django、Laravel自带CSRF防护默认开启。但实际测试里我遇到的典型问题是开发把框架的CSRF中间件给关了——原因往往是前后端分离后接口跨域不好带Token结果干脆全局关闭。排查时先看框架配置里CSRF开关是否存在再确认自定义过滤器是否覆盖了所有需要防护的接口。比如Spring Boot项目里如果有全局过滤器处理XSS但是在做XSS过滤时意外把CSRF Token一并过滤掉了就会出现一个很隐蔽的坑——Token字符被转义后服务端比对永远失败。这类问题在项目实测中并不罕见。7. 我对CSRF这条线的几点实战体会CSRF在漏洞评级里常常被定为中危很多人因此低估了它。但我的实际感受是CSRF的危害大小完全取决于目标接口的重要性。如果一个管理后台的添加管理员修改配置接口存在CSRF风险等级直接拉到高危也不为过。授权测试时我会把CSRF和XSS、短链接、点击劫持放在一起评估而不是孤立看单一漏洞。做测试的人容易犯一个错误——只盯着能否改密码这种直白目标忽略了CSRF在业务逻辑中的放大作用。比如电商站点的修改收货地址绑定手机接口同样存在CSRF风险攻击者可以利用它把受害者的手机号改成自己的后续账号申诉和找回流程就会全面失控。最后提醒一点所有文章里的payload和绕过手法都是我在本机DVWA、Pikachu靶场里验证过的真实环境会有各种变形但攻击链路的核心逻辑是一致的。如果你所在的团队有授权测试项目可以直接拿这些步骤做参考如果只是想自学强烈建议在本地把DVWA整个过一遍——CSRF那几关从Low到High一路打下来你对会话管理、Token机制、同源策略的理解会有一个质的提升。