《xss主机》

一台XSS主机，说白了就是一台被攻击者盯上的服务器，只不过攻击者不偷数据，也不搞勒索，而是拿它当“发射台”，往访客的浏览器里塞JavaScript代码。听起来像黑客电影里的桥段，但这件事每天都在发生。我去年帮一个做二手书交易的朋友看他的小站，打开后台日志，发现有人往商品评论区提交了一段`<img src=x onerror=alert('XSS')>`，他当时没当回事，觉得弹个窗又不会掉肉。结果三天后，所有访问那条评论的用户，浏览器都会悄悄向一个境外IP发送自己的cookie。他站里有两千多个注册用户，其中三百多人的登录凭证就这么被卷走了。

XSS主机不一定是那种配置豪华、带宽充沛的机器。恰恰相反，很多被当作XSS主机的，是那种老旧论坛、个人博客、甚至学校实验室里没人管的测试服务器。攻击者看中的不是它的算力，而是它的“信任度”。浏览器对同一个域名下的脚本有天然信任，你从A站加载的JS，在A站页面上就能为所欲为。所以攻击者会先想办法在A站找到一个存储型XSS漏洞，把恶意脚本存进数据库，然后坐等其他人来访问。这台A站服务器，就成了事实上的XSS主机。

我见过最离谱的一个案例，是一个地方图书馆的预约系统。系统用的是十几年前的CMS，留言板功能没有过滤`<script>`标签。有人提交了一条“预约须知”，里面嵌了窃取管理员会话的代码。管理员一登录后台查看留言，脚本就在他的浏览器里执行，把管理员的session token发到了攻击者的服务器上。攻击者拿到token，直接以管理员身份登录，把整个预约系统的首页改成了赌博广告。图书馆的IT外包公司花了四天才发现，问题不在服务器被入侵，而在那条留言里藏着的几行代码。

防御XSS主机，很多人第一反应是装WAF。WAF有用，但别指望它包治百病。我见过太多WAF被绕过的方式——大小写混写、HTML实体编码、利用浏览器解析差异。真正靠谱的做法，是在输出到HTML页面时，对用户可控的数据做上下文相关的编码。比如在`<script>`标签里输出，就得用JavaScript转义；在HTML属性里输出，就得用HTML属性转义。听起来很基础，但很多开发者就是忘了做。我自己的习惯是，任何从数据库里取出来要显示在页面上的字段，先过一遍`htmlspecialchars`，哪怕它看起来只是个数字。

还有一点，别把XSS主机当成别人的事。你租的VPS、你用的开源建站程序、你随手写的评论组件，只要有一个环节没做好过滤，它就可能变成XSS主机。攻击者不挑食，大厂站搞不动，就去扫那些小站。扫到一个算一个，积少成多，照样能拼出一张巨大的僵尸网络。我那个朋友后来把评论功能整个关掉了，换成了第三方托管评论系统。他说了一句话我印象很深：“我宁愿少几个用户留言，也不想再当一次肉鸡。”

XSS主机不会自己消失。只要还有网站把用户输入直接拼进HTML，只要还有开发者觉得“弹个窗没什么大不了”，这类主机就会一直存在。你能做的，就是别让自己的机器成为其中一台。检查你的输出编码，别信任任何用户提交的内容，哪怕它看起来只是条普通的评论。就这么简单，但也就这么容易被忽略。