XSS 和 CSRF 有什么区别？HttpOnly、SameSite 和 Token 分别防什么？

XSS 是不可信输入被页面当作可执行内容，攻击者因此获得当前页面里的脚本能力。主要防护是按输出上下文正确编码，富文本使用可靠净化，并避免危险的动态执行入口，CSP 可作为额外防线。

CSRF 则利用浏览器会自动携带 Cookie 等凭据，让用户在不知情时触发服务端操作。可以结合 CSRF Token、来源校验、SameSite 和禁止用 GET 修改状态等措施。

HttpOnly 限制脚本读取 Cookie，但不会阻止浏览器发送 Cookie；SameSite 限制部分跨站携带，也有适用范围，不等于完整鉴权。

同时，XSS 可能直接在页面里读取 Token 或发合法形态的请求。因此，两类问题需要分别防，不能认为补了一个 Cookie 属性就安全了。

假设评论内容本来应该作为文字显示。如果应用把它直接放进能够解释 HTML 或执行脚本的位置，不可信内容就可能获得执行能力。

需要按具体输出位置处理来自评论、URL 或数据库的内容。HTML 文本、属性、URL 和 JavaScript 字符串，所需处理并不一样。

因此，不能只做一个全局替换就宣称处理了所有 XSS。尽量使用安全的内容插入方式；必须显示富文本时，使用维护良好的净化工具，并限制允许的结构。OWASP XSS 防护指南区分了这些输出上下文。

CSP 可以限制脚本来源与执行方式，但不应该代替正确编码。配置里随意允许内联脚本或不可信来源，也会削弱它。

假设用户已经登录网站 A，浏览器保存了 A 的登录 Cookie。另一个网站诱导浏览器向 A 发请求，在 Cookie 规则允许的情况下，身份会被自动带上。

攻击者可能读不到 A 的响应，但如果 A 只凭 Cookie 就执行操作，结果仍然可能已经发生。

这也解释了为什么 CORS 不是完整 CSRF 防护。响应不能被读，不等于请求从未到达，也不等于服务端没有修改数据。

OWASP CSRF 防护指南介绍了 Token、来源检查与 Cookie 策略等方式。设计时应该问，这个请求是否确实来自允许的交互，并且用户是否有操作权限？

CSRF Token 还需要正确生成、与会话等上下文关联并校验，不能只放一个固定字符串。Token 不应该进 URL 或被随意记录到日志里。

SameSite 比较的是"站"，不是完整的 Origin。受控程度不同的同站子域，还需要特别考虑，不能把"同站"直接当成"可信"。

如果恶意脚本已经运行在 A 的页面里，它可以利用页面现有的交互能力。有些方案中，它能读到页面里的 CSRF Token；即使不能读取 HttpOnly Cookie，也可能发出浏览器会自动带凭据的请求。

所以，"Cookie 不能被偷走"与"账户不能被操作"，是两件事。

遇到这种情况，修复不可信内容执行入口仍然必要。对于高风险操作，还可以增加重新确认、权限检查和异常监控，但这些是降低损失，不能把已存在的 XSS 当成没事。

如果凭据只能由可信代码显式加到请求头，传统自动携带 Cookie 的 CSRF 条件会不同。但仍要看整个认证流程、Token 存储与请求校验，XSS 风险也没有消失。

不够。标识形式与请求来源是不同问题。服务端仍然需要有效会话、权限与敏感操作防护。

GET 应具有安全语义。浏览器、预加载、爬虫或链接访问都可能触发它。把修改动作藏在 GET 中，不仅增加 CSRF 风险，也违背常见 HTTP 使用约定。

XSS，不可信内容获得了页面执行能力。

CSRF，浏览器被诱导携带已有身份触发操作。

HttpOnly，防脚本读取 Cookie，不防所有账户操作。

SameSite，限制跨站携带，但不是权限与来源检查的全集。

防护组合，输出防护与请求防护分开做，高风险操作再加确认。

我是程序员Sunday。本文收录于 sunday面试指南，原文与配图可继续阅读。