存储型XSS漏洞

2018年，存储一个叫Magento的漏洞开源电商平台爆出严重漏洞。攻击者不需要登录后台，存储只需在商品评论框里提交一段精心构造的漏洞脚本，就能让所有访问该商品页面的存储顾客浏览器沦为“肉鸡”。更讽刺的漏洞是，这个漏洞直到被安全团队曝光前，存储已经在暗网被交易了整整半年——数据泄露的漏洞账单，最终还是存储由那些老老实实填写收货地址的消费者买单。

存储型XSS，漏洞说白了就是存储攻击者把恶意代码“存”进服务器数据库里。你访问哪个页面，漏洞这段代码就跟着哪个页面一起加载。存储它不像反射型那样需要诱导用户点击特定链接，漏洞也不像DOM型那样受限于前端逻辑。存储它像埋在地基里的钢筋，平时看不见，等整栋楼盖好了，地震一来，全塌。

我见过最典型的案例发生在某政务网站。一个信访投诉栏目，本意是让群众反映问题，结果有人往留言框里塞了段JavaScript，专门窃取管理员cookie。管理员每次审核投诉时，浏览器就悄悄把后台会话令牌发到攻击者的服务器上。前后持续了三个月，后台被翻了个底朝天，连某些敏感案件的内部批示都被截走了。你猜怎么着？事后调查发现，开发人员压根没对用户输入做任何过滤，连最基本的HTML实体编码都没转。他们以为政务网站没人敢黑，结果黑客专挑这种“自以为安全”的地方下手。

修复存储型XSS其实不复杂，核心就一条：永远不要信任用户输入。具体操作上，输入侧要校验格式，输出侧要编码转义。比如把<转成<，把引号转成实体字符。但很多团队只做了输入过滤，忽略输出编码——这就像只锁前门不关后窗。攻击者照样能用img标签的onerror属性绕过输入校验，因为有些过滤规则根本拦不住Unicode变体或大小写混写。

还有个容易被忽视的细节：富文本编辑器。这类组件通常允许用户提交带格式的HTML，但你以为它“已经处理过了”，实际上很多开源编辑器只做了基础的标签白名单。我在一次渗透测试中，用<svg/onload=alert(1)>就突破了某知名编辑器的防线。那会儿对方技术负责人还信誓旦旦说“我们用的最新版”，结果一查，他们自定义了配置项，把svg加入了白名单——为了支持某个表情包功能。

说句掏心窝的话，存储型XSS的危害被严重低估了。它不像SQL注入那样直接拖库，也不像文件上传漏洞那样能立刻getshell，但它能悄无声息地控制每个访问者的浏览器。想象一下，一个银行网站的公告栏被植入挖矿脚本，所有在线查看公告的客户电脑都会变成矿工。用户不会察觉，银行也不会主动披露——因为这种攻击没有留下任何破坏痕迹，只有CPU占用率莫名升高。

真正要命的不是技术本身，而是人的惰性。很多开发者觉得“我们做了安全测试”，但所谓测试不过是拿扫描器跑一遍，扫不出通用payload就宣告安全。可攻击者用的是上下文相关的绕过技巧，比如利用javascript:协议配合location跳转，或者借道CSS的expression属性（IE时代遗留的坑）。扫描器查不出这种组合拳，只有人工审计代码逻辑，看每个输出点是否做了上下文感知的编码。

最后提醒一句：如果你维护的站点有任何用户生成内容的功能——评论、留言、昵称、甚至头像上传时的文件名——赶紧去查数据库里有没有存着<script>字样。别等安全报告发到你邮箱才想起来补漏洞。到那时候，攻击者可能已经用你的服务器发了一整年的垃圾邮件，而你连对方IP都找不到。

最新评论