游客发表
XSS跨站脚本漏洞：一个被低估的站脚浏览器信任危机
2019年，某大型电商平台的本漏安全工程师在后台日志里发现一串诡异的请求——攻击者把一段JavaScript代码伪装成商品价格参数提交。当运营人员点开商品编辑页面时，站脚这段代码在管理后台执行，本漏悄悄创建了一个拥有最高权限的站脚账号。整个过程没有突破任何防火墙，本漏没有暴力破解密码，站脚仅仅因为后台页面信任了URL里的本漏参数。
这就是站脚XSS（跨站脚本）的典型攻击链。它的本漏本质不是服务器被入侵，而是站脚浏览器对页面内容的信任被滥用。攻击者不直接攻击你的本漏网站，而是站脚把恶意脚本注入到你的页面里，借你的本漏手打你自己。
最常被忽视的站脚是存储型XSS。攻击者把恶意代码存在服务器数据库里，比如评论区、用户昵称、甚至是一段富文本。其他用户访问时，这些代码就跟着页面一起加载。2018年某社交平台就出过这事——用户头像的图片URL字段没有过滤，攻击者把URL改成`">`，结果所有访问他主页的人，cookie都被悄悄发送到攻击者的服务器。
反射型XSS更隐蔽。它不存数据库，而是藏在链接里。你收到一条消息：“看看这张照片，你的账号可能被盗了！”链接指向`http://bank.com/transfer?to=attacker&amount=1000&callback=`。如果银行网站没有对callback参数做转义，脚本就在你的浏览器里执行。你以为在访问银行官网，实际上页面里运行着攻击者的代码，正在修改转账指令。
DOM型XSS最反直觉。它甚至不经过服务器，纯粹在前端JavaScript里发生。比如一个搜索页面用`document.write()`把URL参数直接写入页面，攻击者构造`#`，浏览器解析时就把onerror当事件执行了。这种漏洞，服务器日志里连痕迹都找不到。
防护其实不复杂。核心就是两条：第一，对任何要插入HTML的内容做转义，`<`变成`<`，`>`变成`>`，引号变成`"`。第二，用CSP（内容安全策略）告诉浏览器“只准执行我白名单里的脚本”。但现实里很多开发者觉得“用户输入的都是正常内容”或者“我们内部系统没人攻击”，结果漏洞就藏在那些被忽略的搜索框、参数转发、甚至错误提示页面里。
我见过最讽刺的案例——某安全公司自己的产品演示页面，因为把用户输入的“公司名称”直接拼进页面标题，被白帽黑客用XSS拿到shell。连安全公司都栽在这上面，可见这个漏洞多么容易让人麻痹。
XSS真正可怕的地方在于，它攻击的不是技术漏洞，而是“信任关系”。浏览器信任页面，页面信任数据，数据来自用户——链条上任何一环的疏忽，都能被利用。而且随着前端框架越来越复杂，Vue、React这些虽然默认转义，但开发者一旦用`v-html`或`dangerouslySetInnerHTML`绕过防护，漏洞照样存在。
最后说个实操建议：用现成的XSS过滤库，别自己写正则。自己写的过滤逻辑，十有八九会被编码变体绕过——比如`