xss漏洞

一个下午，黑客往论坛的搜索框里输入了这样一段代码：<script>alert('你被黑了')</script>。页面弹出一个对话框，管理员后台没有记录任何异常。三天后，整个用户数据库被拖走。

XSS漏洞就这么简单。它不攻击服务器，不破解密码，而是利用网站对输入内容的信任——你提交什么，它就原样展示什么。攻击者把恶意脚本藏在URL参数、评论区、甚至用户名里，等别人点开页面，脚本就悄悄执行。你以为在看新闻，其实浏览器已经替黑客干了一票。

我见过最讽刺的案例：一家安全公司的官网，在“联系我们”的留言框里存在存储型XSS。攻击者提交了一条包含盗取Cookie脚本的留言，后台管理员一查看留言，会话凭证就发到了攻击者的服务器上。管理员自己成了突破口，这比直接攻破防火墙容易多了。

XSS分三类。反射型是一次性的，你点开带恶意参数的链接，脚本执行完就消失，像骗你输入密码的钓鱼页面。存储型最危险，恶意脚本被保存在服务器数据库里，每个访问页面的人都会中招——论坛帖子、商品评价、用户头像，都是理想的藏身处。DOM型更隐蔽，它不经过服务器，纯靠前端JavaScript的DOM操作触发，很多自动化扫描工具根本测不出来。

有人觉得只要过滤了<script>标签就万事大吉。拉倒吧。编码绕过、事件属性、伪协议，攻击者的变形手法比你想的多。一个<img src=x onerror=alert(1)>就能绕过只过滤尖括号的过滤器。更别说还有CSS注入、SVG载荷，你封一个，人家换个姿势又来。

防御的核心不是黑名单，是输出编码。把用户输入当成纯文本处理，而不是可执行的HTML。前后端都要做，Content-Security-Policy头能限制脚本来源，HttpOnly标记能保护Cookie不被读取。但最根本的，是开发时别信任何输入——哪怕是你自己的数据库里取出来的数据，渲染时也得转义。

有一次我测试一个社交平台，发现它的私信功能存在反射型XSS。我把恶意链接发给一个朋友，他一点，我就在后台看到他的会话令牌。整个过程没碰密码，没碰服务器，就靠一个精心构造的URL。朋友后来问我怎么做到的，我说：“你信任了网址栏里的链接，而网站信任了URL参数里的内容。”

XSS漏洞之所以泛滥，是因为它攻击的是“人机信任链”最薄弱的环节——浏览器把数据和代码混为一谈。只要你还在网页里展示用户输入，只要你没在输出前做严格的编码处理，这个洞就永远存在。补丁能修单个漏洞，修不了思维惯性。