XSS蠕虫攻击的原理与历史案例分析

当脚本注入不止一次，而是自行复制、在受害者浏览器间跳跃时，XSS便脱离了单纯的窃取信息，演变为一种蠕虫式自传播。这个现象在安全社区里被冠以“XSS蠕虫”，其核心在于利用受信任的页面作为载体，让恶意代码在用户交互时自动触发并向社交网络或评论系统投递自身副本。

蠕虫机制剖析

存储型 XSS 让攻击者的 <script> 代码永久驻留在数据库或页面模板里。蠕虫的关键步骤通常包括：

• 读取当前登录用户的身份标识（如 Cookie、OAuth token），确保后续请求拥有完整权限。
• 利用 AJAX 或表单自动提交，将同一段恶意脚本写入其他用户可编辑的字段（状态、签名、留言等）。
• 触发页面渲染时，脚本再次执行，完成新一轮的复制——形成闭环。

因为代码运行在受害者的浏览器中，所有请求都携带合法的身份凭证，目标站点往往难以辨别是“用户本人”还是“蠕虫”。这也是 XSS 蠕虫能够在数分钟内跨越数千用户的根本原因。

典型案例回顾

• Samy 蠕虫（MySpace，2005）：攻击者在个人资料页写入 <script>...</script>，脚本在页面加载时自动将自身写入访问者的“访客墙”。短短数小时内，感染用户突破百万，导致 MySpace 暂停服务。
• 百度空间 XSS 蠕虫（2009）：利用留言板的 HTML 过滤缺陷，植入 iframe 脚本，脚本读取登录用户的 cookie 并向自己的空间写入同样的代码，结果在数千个空间中形成链式扩散。
• Twitter “Self-XSS” 演示（2010）：攻击者在公开推文中嵌入 script，利用 Twitter 的“转发”机制让每个点击链接的用户自动在其时间线上发布带有恶意脚本的转发，形成社交网络层面的快速复制。
• Google+ XSS 蠕虫（2011）：通过在公开的“+1”评论框写入 img 标签的 onerror 事件，脚本在页面渲染时触发，随后利用 Google+ 的 API 自动在用户的“分享”流中植入相同代码，导致数万用户短时间内收到同样的恶意链接。

防御思考

从技术层面看，单纯的输入过滤已难以抵御自复制脚本。业界倾向于在输出阶段统一使用内容安全策略（CSP）配合 HttpOnly、SameSite Cookie 标记，限制脚本的执行来源；同时对可编辑字段实行白名单 HTML、严格的 DOMPurify 清洗。对社交平台而言，限制自动化写入的频率阈值、对异常的 AJAX 请求进行行为分析，也是一道不可或缺的防线。