早上七点四十三分，检测安全运营平台的到目洞告警列表里跳出一条红色条目——目标URL带着一个不太起眼的问号参数，后面跟着一串编码过的存跨字符。我点开payload一看，站漏<script>alert(1)</script>，检测就这么直白地躺在那里，到目洞连混淆都懒得做。存跨

这不是站漏什么高深攻击。攻击者往搜索框里塞了一段脚本，检测服务器没过滤，到目洞浏览器没拦，存跨直接执行了。站漏整个过程不到三秒。检测可这三秒，到目洞足够让一个普通用户的存跨会话cookie被偷走，足够让攻击者在受害者浏览器里干任何事——改页面、发请求、模拟操作，全看攻击者心情。

跨站漏洞（XSS）的可怕之处在于它不挑系统。银行门户有，政府网站有，你楼下便利店那个积分商城也有。去年我测试过一个内部OA系统，漏洞点藏在“个人签名”里，员工改个签名，脚本就存进了数据库。之后每个打开他资料页的人，都成了脚本的宿主。那签名栏连个长度限制都没有，输入框防了个寂寞，后端存储时也没做转义，前端渲染时更没做过滤——三层防护，一层没上。

这类漏洞的检测逻辑其实挺机械的。先找所有带参数的可交互点，比如搜索框、登录框、评论留言区，再往里面塞各种变形payload，观察响应是否原样返回。但真正的难点不在检测，在于确认“可利用性”。很多扫描器报出一堆“疑似XSS”，打开一看全是反射型，而且只弹个alert框，自嗨用。真正危险的是存储型——你插进去的脚本被存到服务器上，任何访问那个页面的用户都可能中招。

我印象最深的一次，是某电商平台的优惠券领取页面。攻击者把payload藏在优惠券代码里，管理员在后台查看领券记录时，脚本在管理员浏览器里执行，直接调接口给攻击者账号发了一张满减券。你说这算大危害吗？不算。但要是攻击者把目标换成管理员修改商品价格的接口呢？换个思路，危害就上去了。

修复跨站漏洞，别指望开发者自觉。最有效的办法是在源头统一做输出编码——所有动态内容渲染前，按HTML上下文转义。前端框架像Vue、React自带转义机制，但总有人用v-html、dangerouslySetInnerHTML把安全机制绕过去。你拦不住手痒的开发者，那就只能在网关层加WAF规则，或者用CSP（内容安全策略）限制脚本来源。CSP这东西挺实用，设置script-src 'self'，能拦掉大部分外联脚本攻击。但内联事件属性、javascript:伪协议这些，还得靠代码层处理。

检测到漏洞只是第一步。真正要紧的是评估它的实际影响——这个URL是登录页还是公开页？有没有敏感操作依赖这个页面的请求？如果只是展示型页面，危害有限，可以先记录后处理。但如果涉及用户信息查询、交易操作、权限修改，那就得按紧急事件处理，该下线下线，该回滚回滚。别等攻击者先你一步把漏洞用了，才后悔当初没早点看那条告警。