文章总结： 本文研究ChromeXSS审计器被反手利用为侧信道窃取敏感数据的技术。通过X-XSS-Protection:1;mode=block配置下页面被清空的行为，利用iframe的contentWindow.length属性作为跨域布尔信号，判断审计器是否触发，进而逐字符提取UID或Token等敏感信息。文章指出安全机制配置方式可能比机制本身更重要，此类滥用风险也是该机制最终被废弃的原因。 综合评分： 75 文章分类： 漏洞分析,WEB安全,红队
XSS研究：一个被废弃的浏览器功能，竟成赏金猎人窃取Token的完美侧信道
原创
升斗安全XiuXiu 升斗安全XiuXiu
升斗安全
2026年9月5日 00:06 广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
【文章说明】
- 目的：本文内容仅为网络安全技术研究与教育目的而创作。
- 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
- 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
- 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。
阅读即代表您同意以上条款。
你有没有想过，浏览器里一个本该保护用户安全的功能，反而可能成为攻击者手里的“探测雷达”？今天要聊的，就是 Chrome 里那个老牌防御机制【XSS 审计器】，在特定配置下如何被反手利用，变成窃取敏感数据的“帮凶”。
事情的起因是 James 提了一嘴：Chrome 的 XSS 审计器有个拦截模式。我心想，这玩意儿要是被触发，页面会被整个清空，那如果我们能观察到“页面是否被清空”，是不是就等于拿到了一个布尔值？一个“是或否”的信号？这个信号，能不能用来做点更危险的事？
先看看审计器会不会“动手”
当服务器返回的头里带上 X-XSS-Protection: 1; mode=block，一旦浏览器检测到疑似 XSS 的请求，它会直接把页面撸掉，什么都不剩。那怎么知道页面被撸了没？
灵光一现：如果目标页面里嵌了一个 iframe，我跨域是读不了它内部 DOM 的，但 contentWindow.length 这个属性，所有现代浏览器都允许跨域访问。于是：
<iframe onload="alert(this.contentWindow.length)" src="http://somedomain/with_iframe"></iframe>
如果目标页里有 1 个 iframe，弹窗显示 1；没有，显示 0；有多个，显示对应数量。这个数字，就变成了审计器是否触发的“晴雨表”。审计器一触发，页面没了，length 归零；没触发，length 就是原始值。
从“有没有”到“是多少”——暴力猜 UID
光知道触发没触发还不够，我想用这个布尔条件去“读”东西。怎么读？如果目标页面里有一段内联脚本，里面写着用户的 UID，比如：
<?phpheader("X-XSS-Protection: 1; mode=block");?><iframe></iframe><script>uid = 1337;</script>
我能不能通过不断构造恶意参数，去“猜”出这个 UID？思路是这样的：我注入一个伪造的 XSS 向量，里面写 uid = 1;，然后观察审计器是否触发。如果触发了，说明我猜错了；如果没触发，说明我猜的值和页面里的真实值“长得像”，审计器没觉得有问题。于是我从 1 猜到 9999，每次加 1，总有一次会命中。
关键点在于，XSS 审计器会忽略闭合的 标签，但末尾的换行符 %0a 是触发检测的必要条件。所以我的伪造向量长这样：
?fakevector=
评论