XSS 和 CSRF 有什么区别？如何防范？

简化版

XSS 是攻击者把恶意脚本注入页面，让它在用户浏览器中执行；CSRF 是诱导已登录用户在不知情时向目标站点发起请求。XSS 重点防脚本注入，CSRF 重点防跨站伪造请求。常见防护包括输入输出转义、CSP、HttpOnly Cookie、SameSite、CSRF Token。

详细版

XSS 的核心是“执行了不该执行的脚本”。如果页面把用户输入直接当 HTML 插入，就可能中招。攻击脚本可以窃取 token、篡改页面、发起请求。

CSRF 的核心是“借用用户登录态发请求”。如果站点使用 Cookie 登录，恶意网站可以诱导浏览器向目标站点发送请求，因为 Cookie 会自动携带。

防 XSS：

输出转义。
避免不可信 HTML。
使用 CSP。
Cookie 设置 HttpOnly。

防 CSRF：

SameSite Cookie。
CSRF Token。
校验 Origin/Referer。
重要操作二次确认。

完整版教学

一、XSS 是什么

XSS 指跨站脚本攻击。攻击者通过评论、昵称、搜索词、富文本等入口，把恶意脚本注入页面。

常见类型：

存储型：恶意内容存进数据库，其他用户访问时执行。
反射型：恶意脚本通过 URL 参数反射到页面。
DOM 型：前端 JS 把不可信数据写入 DOM 导致执行。

防护重点是不要让不可信内容变成可执行脚本。

二、CSRF 是什么

CSRF 指跨站请求伪造。用户已经登录 A 网站，恶意 B 网站诱导用户访问后，浏览器可能自动携带 A 网站 Cookie 发起请求。

攻击者不一定能读取响应，但只要能触发状态改变就可能造成危害，例如改邮箱、转账、下单。

所以 CSRF 常针对基于 Cookie 的登录态。

三、防护策略

防 XSS：

框架默认插值通常会转义，不要轻易使用危险 HTML 插入。
富文本要做白名单过滤。
设置 CSP 限制脚本来源。
敏感 Cookie 使用 HttpOnly，降低被 JS 读取风险。

防 CSRF：

Cookie 设置 SameSite=Lax 或 Strict。
重要请求携带 CSRF Token。
服务端校验 Origin 或 Referer。
修改类接口不要使用 GET。

四、面试追问与工程落地

面试官常问：“XSS 和 CSRF 谁更危险？”

不能简单比较。XSS 一旦成功，攻击脚本运行在同源环境中，能做很多事，甚至可以绕过部分 CSRF 防护。CSRF 更依赖 Cookie 自动携带机制，主要攻击状态变更操作。

工程中安全防护必须前后端配合。前端负责减少注入面，后端负责鉴权、校验 token、限制来源和审计异常行为。

五、上下文编码、净化与浏览器纵深防御

XSS 防护不能只说“转义尖括号”，因为 HTML 文本、属性、URL、JavaScript 字符串的编码规则不同。默认使用 textContent 或框架安全插值；确需富文本时用经过维护的 HTML sanitizer 白名单净化，再送入 innerHTML 等注入 sink。

数据进入位置	主要风险	首选控制
HTML 文本	标签/实体注入	文本 API、HTML 上下文编码
HTML 属性	属性逃逸、事件处理器	属性 API、严格白名单
URL	`javascript:` 等危险协议	URL 解析与协议白名单
`innerHTML`	DOM XSS	sanitizer + Trusted Types（可用时）
JS 执行 sink	任意代码执行	禁止 `eval`/字符串定时器

CSP 应采用 nonce/hash 的严格策略作为纵深防御，不是替代输出编码和净化。Trusted Types 可要求危险 DOM sink 接受经策略创建的 TrustedHTML 等类型，但它本身不提供净化算法，策略仍需调用可靠 sanitizer；旧浏览器兼容性也要评估。

六、CSRF Token、SameSite 与攻击链推演

CSRF 成立通常需要三个条件：浏览器自动携带身份、攻击者能构造有效状态变更请求、服务端无法区分用户意图。同步 token 或双提交 token 应使用不可预测值并在服务端校验，配合 Origin/Referer 与 SameSite 形成多层防御。

用户已登录 bank.example（Cookie）
        ↓ 访问 evil.example
恶意表单 POST bank.example/transfer
        ↓ 浏览器可能自动携带 Cookie
服务端若无 Token/Origin/业务确认 → 状态被改变

SameSite=Lax 能阻挡很多跨站子请求携带 Cookie，但有顶级导航、方法和兼容边界；SameSite=None 必须配 Secure。另外 SameSite 的“site”不等于 same-origin，子域与协议语义需要按实际 cookie/浏览器规则判断，不能把它当唯一防线。

假设转账接口只校验 32 字节随机 CSRF token，攻击者不能读取页面时猜中概率约为 1 / 2^256；但若站点已有 XSS，脚本可在同源中读取页面 token 或直接发请求，所以修复 XSS 往往比叠加 CSRF 头更根本。

HttpOnly 能防脚本直接读取 Cookie，却不能阻止同源恶意脚本调用接口；重要操作还应重新认证、校验业务状态、幂等和审计。GET 不做状态修改是基础约束，但把 POST 当作天然安全同样错误。

记忆钩子：XSS 是攻击者进入你的 origin 执行，CSRF 是攻击者留在别的 site 借浏览器带凭证；前者一旦成功常能绕过后者的页面级防线。

七、常见误区与追问

误区：所有用户输入统一 HTML 转义就能防住全部 XSS。 不同输出上下文规则不同，URL、属性和 JS sink 需要各自安全 API。
误区：设置 CSP 后可以不做输出编码和富文本净化。 CSP 是纵深防御，配置错误、允许源和兼容问题都可能留下空隙。
误区：HttpOnly Cookie 能阻止 XSS 代用户操作。 它只禁止读取 Cookie，脚本仍可在同源环境发起已认证请求。
追问：DOM 型 XSS 与反射型 XSS 的区别是什么？ DOM 型漏洞在客户端把不可信数据送入危险 sink，反射型由服务端把请求数据拼回响应。
追问：CORS 能防 CSRF 吗？ 不能，很多跨站状态变更请求无需读取响应；应使用 SameSite、Token 和 Origin 校验。
追问：CSRF Token 为什么不能只放 Cookie？ Cookie 会被浏览器自动随跨站请求携带，服务端还需要一个攻击者无法构造的独立证明。
追问：XSS 和 CSRF 可以如何联动？ XSS 在目标同源执行后可读取非 HttpOnly 数据、获取 token 或直接操作接口，从而绕过多种 CSRF 防线。

八、加强记忆

XSS 按“数据源 → 传播 → 危险 sink”排查，用上下文安全 API、富文本净化、严格 CSP 与 Trusted Types 分层阻断；CSRF 按“自动凭证 + 可构造请求 + 无意图校验”排查，用 SameSite、随机 Token、Origin 校验和关键操作确认。HttpOnly 只减少凭证被读，CORS 只管响应可读性，都不能单独解决整类攻击。

简化版

详细版