XSS 和 CSRF 的区别、原理和防御方式是什么？｜字节跳动测开面经解析

60 秒回答模板

可以先用一句话区分：XSS 攻击用户看到和执行的页面内容，CSRF 攻击用户已经建立的登录态。XSS 的原理是把不可信输入变成页面可执行脚本，常见类型有存储型、反射型和 DOM 型，防御重点是按上下文输出编码、富文本白名单清洗、CSP、HttpOnly Cookie、框架默认转义和依赖治理。CSRF 的原理是浏览器会自动携带目标站点 Cookie，攻击者虽然通常读不到响应，却能触发转账、改密码、发帖等状态变更操作。防御重点是 SameSite Cookie、CSRF Token、Origin 或 Referer 校验、关键操作二次确认，以及避免用 GET 做有副作用的动作。测试时要分别覆盖输入注入点、渲染上下文、状态变更接口、跨站触发路径和浏览器策略差异。

考点 本质区别

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

攻击目标差异

XSS 的目标是让恶意脚本进入并执行在可信页面上下文中，进而读取页面数据、发起操作或劫持用户交互。CSRF 的目标不是注入脚本，而是借用用户已经登录的浏览器身份，让目标站点收到一笔看似来自用户的合法请求。一个偏内容执行，一个偏请求伪造。

XSS 的执行机制

XSS 通常来自不可信输入没有被正确处理，例如评论、昵称、搜索词、URL 参数或前端拼接 HTML。存储型会把 payload 写入服务端并影响后续访问者，反射型依赖当前请求回显，DOM 型发生在前端脚本处理 URL、消息或接口数据时。关键风险在于输入跨过了数据和代码的边界。

CSRF 的触发机制

CSRF 利用浏览器对 Cookie 和认证信息的自动携带机制。攻击者可以通过表单提交、跳转、图片请求或部分简单跨域请求触发目标站点接口。即使攻击者不能读取响应，只要接口只依赖 Cookie 认证且缺少请求意图校验，状态变更就可能成功。

防御 XSS 的重点

XSS 防御不能只靠过滤某个关键字，而要按渲染上下文处理。HTML 文本、属性、URL、JavaScript 字符串和 CSS 的编码规则不同；富文本要做白名单清洗；模板引擎默认转义不要随意关闭；CSP 能降低脚本执行面；HttpOnly Cookie 能减少会话凭据被脚本读取的风险。

防御 CSRF 的重点

CSRF 防御要证明请求确实来自用户在本站的交互。常见手段包括 SameSite Cookie 限制跨站携带、每次表单或请求携带不可预测的 CSRF Token、校验 Origin 或 Referer、敏感操作要求密码或验证码确认。接口设计上还应避免 GET 修改状态，并保证关键操作具备幂等和审计能力。

易错点

把 XSS 和 CSRF 都简单说成跨站攻击，没有说明一个是脚本执行，一个是请求伪造。
认为只要接口开启 CORS 限制就不会有 CSRF，忽略浏览器自动携带 Cookie 的机制。
只过滤 script 字符串，忽略属性、URL、DOM API、富文本和模板渲染上下文。
把 Token 放在固定 Cookie 中又不做额外校验，导致请求仍然可能被自动携带。

面试官追问

HttpOnly Cookie 能完全防止 XSS 吗？

不能。HttpOnly 只能阻止脚本直接读取 Cookie，但 XSS 脚本仍然可以在当前页面发起请求、读页面数据、诱导用户操作或篡改 DOM。它是降低会话泄露风险的措施，不是 XSS 的根治方案。

CORS 能防住 CSRF 吗？

不能简单认为可以。CORS 主要控制跨域读取响应和非简单请求的许可，传统表单提交等路径仍可能带上 Cookie 发起状态变更。CSRF 仍需要 Token、SameSite、Origin 校验等机制。

SameSite Cookie 是否足够作为唯一 CSRF 防御？

多数现代场景下 SameSite 很有价值，但不宜作为唯一防线。需要考虑老浏览器、跨站登录跳转、第三方嵌入、子域关系和特殊业务流程。高风险操作仍建议配合 Token 或二次确认。

为什么不能只过滤 script 标签来防 XSS？

XSS payload 不只存在于 script 标签，还可能出现在事件属性、URL 协议、SVG、样式、模板注入和前端 DOM API 中。正确做法是按上下文编码和白名单清洗，而不是依赖黑名单。