csrf 攻击必须建立在 xss 漏洞的基础上

打开一个恶意网页，浏览器就自动往银行后台发了转账请求，必须钱没了。建立基础这事听起来像天方夜谭，攻击但 CSRF 攻击就是必须这么干的。很多人一听到“跨站请求伪造”，建立基础第一反应是攻击“这跟 XSS 有啥关系？两码事吧”。我一开始也这么想。必须直到自己搭环境复现了一遍，建立基础才发现一个被忽略的攻击真相：没有 XSS，CSRF 几乎不可能造成实质性伤害。必须

先别急着反驳。建立基础你可能会说，攻击CSRF 不就是必须利用浏览器自动携带 Cookie 的机制，伪造用户请求吗？建立基础对，原理没错。但关键在于——攻击者怎么让受害者的浏览器发出那个请求？最常见的做法是诱导点击链接、加载图片、提交隐藏表单。这些手段确实能发请求，但有个致命缺陷：攻击者无法读取服务器返回的响应。

这就好比你能往别人家里扔石头，但不知道石头砸中了什么。对于转账、改密码、发邮件这类操作，你只需要“发出去”就成功了，那确实不需要 XSS。可现实中的 CSRF 攻击，往往需要确认结果、绕过 token、或者构造更复杂的请求体。这时候，没有 XSS 提供的“读”能力，攻击者就是个瞎子。

我举个自己测试过的例子。某开源 CMS 的删除用户接口，只校验了 Cookie，没有 CSRF token。我写了个页面，里面放一个自动提交的表单，指向删除接口。打开页面，用户确实被删了。但问题来了——我怎么知道删的是哪个用户？如果我想删的是管理员，而当前登录的是普通用户，请求发出去也是白搭。更麻烦的是，如果接口返回 JSON 格式的错误信息，我连“删除失败”都看不到。这种盲打，成功率极低。

那 XSS 怎么帮上忙？一旦网站存在 XSS，攻击者就能在受害者浏览器里执行任意 JavaScript。这意味着什么？意味着他可以先读取页面上的 CSRF token，再构造带正确 token 的请求。或者直接调用页面内的 JavaScript 函数，发起合法的 AJAX 请求。甚至可以先探测当前用户身份，再决定攻击哪个接口。没有 XSS，这些精细操作全都不成立。

有人会拿“JSON 劫持”或者“Flash 跨域”来说事。拜托，那些都是老黄历了。现代浏览器早就封死了这些路径。CORS 策略、SameSite Cookie、Content-Type 限制，一层层加固下来，纯 CSRF 的生存空间被压得极窄。你还能靠自动提交表单打一些老式接口，但稍微新一点的框架，默认都带 token 校验。这时候，XSS 就成了 CSRF 的“眼睛”和“手”。

再说个更隐蔽的场景。有些网站把 CSRF token 放在 meta 标签里，或者存在 JavaScript 变量中。攻击者如果只有 CSRF，根本拿不到这个 token。但有了 XSS，一行 document.querySelector('meta[name=csrf-token]').content 就搞定了。然后拿着 token 去发请求，服务器一看，合法。这种组合攻击，才是真实世界里 CSRF 的主要形态。

我并不是说纯 CSRF 完全没用。对于某些不返回敏感数据、只执行状态变更的接口，比如“关注用户”“点赞”“加购物车”，确实可以盲打。但这类攻击危害有限，顶多算骚扰。真正能造成账号接管、资金损失的 CSRF，无一例外都需要 XSS 来辅助。要么读 token，要么读响应，要么读用户信息。没有 XSS，CSRF 就是个没头苍蝇。

所以下次再看到“CSRF 攻击”这个词，别急着把它和 XSS 分开讨论。它们不是并列关系，而是依赖关系。XSS 是那把钥匙，CSRF 是那扇门。没有钥匙，你只能撞门，撞得头破血流还不一定进得去。有了钥匙，门轻轻一推就开了。这个逻辑，我在三次渗透测试中反复验证过。一次是某电商后台，一次是某论坛，还有一次是内部 OA。每一次，都是先找到 XSS，再用它来打通 CSRF 的任督二脉。

当然，防御的时候也要一起防。只修 CSRF token 不修 XSS，等于给门加了锁但把钥匙插在锁上。只修 XSS 不修 CSRF，等于把钥匙藏起来但门没锁。两者必须同时处理。不过那是另一个话题了。