跨网站脚本

凌晨三点，跨网我的站脚一个程序员朋友发来截图——他的博客后台被塞满了红色告警。点开详情，跨网攻击载荷不过是站脚一段伪装成用户昵称的JavaScript。他挠头：“我明明过滤了尖括号啊。跨网”我看了眼代码，站脚问题出在他只过滤了<script>，跨网却没管<img onerror>。站脚这就是跨网跨网站脚本（XSS）的日常：攻击者不跟你拼防御强度，只找你的站脚思维盲区。

XSS的跨网核心漏洞，说白了就是站脚网站把用户输入当成了自己的代码来执行。你提交一个留言，跨网服务器原样存进数据库，站脚下次别人访问时原样吐出来——如果这个“吐出来”的跨网过程没做转义，那你的留言里夹带的<script>alert(1)</script>就会在受害者浏览器里活蹦乱跳。更阴险的是，攻击者根本不需要弹窗吓人，他可以偷走你的session cookie，冒充你发帖，甚至读取你当前页面的敏感数据。我见过最狠的一次，某电商后台被注入一段脚本，专门在支付回调时篡改金额——用户看到的是99元，实际扣款却是9999元，等发现时钱早进了攻击者的账户。

有人觉得，只要不用用户输入拼HTML就安全了？天真。现代前端框架（React、Vue）默认转义，但开发者一旦用了v-html或dangerouslySetInnerHTML，等于亲手把防御门拆了。还有URL参数、HTTP头、甚至JSONP接口的callback参数，都是XSS的藏身地。去年某知名论坛爆出存储型XSS，起因是编辑器的“粘贴为纯文本”功能没处理<svg/onload>这种老掉牙的向量——攻击者只花十分钟写了个爬虫，自动扫描所有帖子里的“回复”按钮，只要有人点开就被种下挖矿脚本。你猜那个论坛修了多久？整整两周，因为数据清洗要回溯所有历史帖子。

别指望WAF能拦住所有变体。真正的防线只有两条：一是对所有输出做上下文感知的编码——HTML属性里用属性编码，JavaScript字符串里用JS编码，别拿一套转义函数通吃天下。二是设Content-Security-Policy，把脚本来源锁死在自己域名下，就算注入成功也执行不了。这两招配合，能挡掉九成以上的攻击。剩下的，靠的是你写代码时多问一句：“这段数据，用户能控制吗？如果能，它最终会出现在哪个上下文里？”

我见过太多团队把XSS当低危漏洞处理，直到某天用户数据被批量拖走才慌神。安全这行，没有“补一次就完事”的捷径。攻击者在暗处盯着你的每一次更新，你每写一行innerHTML，都是在给他们递刀。下次提交代码前，不妨先用document.cookie想想：如果这段字符串是别人输入的，我能接受它在我浏览器里跑吗？