xss攻击测试

我把一个弹窗脚本塞进了自己写的击测留言板，页面刷新那一刻，击测alert框像只青蛙一样蹦出来。击测我盯着那个写着“hello”的击测弹窗，后背有点发凉——这玩意儿要是击测落在别人手里，弹出的击测可就不是hello了。

XSS全称Cross-Site Scripting，击测跨站脚本攻击。击测名字听着绕，击测本质却直白：攻击者把恶意脚本塞进网页，击测让它在别人的击测浏览器里执行。我测试的击测留言板就是个典型靶子，输入框没做任何过滤，击测脚本原样存储，击测其他用户一访问就中招。击测存储型XSS，最阴的那种，像地雷埋在你必经之路上。

测试过程比想象中无聊。先试基本的<script>alert(1)</script>，被过滤了。再试大小写混合<ScRiPt>，还是被拦。最后用<img src=x onerror=alert(1)>，成了。绕过过滤的快乐持续不到三秒，我意识到一个更严肃的问题：如果我把这段代码换成窃取cookie的脚本，所有访问者的登录态都会被我拿走。管理员账号？那不过是多等几分钟的事。

有些人觉得XSS是小打小闹，不如SQL注入直接拿数据来得痛快。这种想法错得离谱。我见过一个真实案例：某电商平台的搜索框存在反射型XSS，攻击者构造一条恶意链接，诱导客服点击，然后冒充客服给用户发退款钓鱼消息。整个攻击链里，XSS只是起点，却撬动了整个信任体系。弹窗只是证明漏洞存在的烟火，真正的杀伤力在于攻击者能冒充你，在你眼皮底下做任何事。

防护手段其实不复杂。输出编码是基本功，把<变成<，让浏览器把用户输入当纯文本处理。输入过滤是第二道闸，但别指望它万能——onerror、javascript:这类伪协议总能找到漏网之鱼。CSP（内容安全策略）是最后防线，告诉浏览器哪些脚本能执行，即使被注入也能拦下一部分。三层都做好，基本能挡住九成攻击。剩下的那成，需要你持续关注新绕过技巧。

我后来给那个留言板加了白名单标签过滤，只允许<b>和<i>，其他全部转义。再测试时，脚本变成了一行无害的字符，安静地躺在页面上。那种感觉很奇怪，像驯服了一头野兽。但我知道它只是暂时沉睡，互联网上总有新的攻击手法诞生，总有粗心的开发者留出缝隙。

做XSS测试最大的收获不是技术细节，而是一种警惕感。每次在网页上输入内容，我都会下意识想：这段数据会被怎么处理？会不会有人利用它做点什么？这种偏执可能有点病态，但在一个连弹窗都能成为武器的地方，保持怀疑不算坏事。