XS-Leak 跨站信息泄漏实战指南：浏览器侧信道 Oracle 分类、XS-Search 方法论与防御排查（PayloadsAllTheThings）-开发者社区

网络安全
应用安全
渗透测试

【免费下载链接】PayloadsAllTheThings

A list of useful payloads and bypass for Web Application Security and Pentest/CTF

项目地址：https://gitcode.com/GitHub_Trending/pa/PayloadsAllTheThings

本文以 PayloadsAllTheThings 仓库 XS-Leak/README.md 为核心骨架，系统讲解 Cross-Site Leaks（XS-Leaks）这类无需读取响应体即可推断目标源敏感信息的侧信道攻击：从攻击原语（Attack Primitives）到 XS-Search 逐字符爆破，再到 Timing、Frame Counting、Cache Probing 等跨站 Oracle 的具体实现，并结合仓库中 CORS Misconfiguration、Clickjacking、CSS Injection、XSS Injection/4 - CSP Bypass.md 等相邻模块，给出可复用的检测代码、测试工具与防御视角。读完本文，你将掌握如何把"响应体不可读"的限制转化为可观测的布尔 Oracle，并能在 Bug Bounty 与 CTF 中独立完成 XS-Leak 的探测与利用。

什么是 XS-Leak

Cross-Site Leaks（XS-Leaks）是一类侧信道（side-channel）漏洞：攻击者可以在不读取目标源（target origin）响应体的前提下，推断出敏感信息。它利用的是浏览器的行为差异、时序差异（timing differences）以及可观测的副作用（observable side effects），而不是传统 XSS 那样直接读取页面数据再外带。

与经典攻击的对比可以更清楚地说明其定位：

CORS 攻击依赖服务端错误地放行跨域读取（如Access-Control-Allow-Origin反射攻击源），详见仓库 CORS Misconfiguration/README.md；
XSS 攻击需要能把脚本注入目标页面上下文；
XS-Leak 攻击则完全不同：即使目标响应体完全不可读、即使没有注入点，只要浏览器暴露出"这个请求花了多久""页面加载了几个 iframe""这个资源是否命中缓存""导航是否被拒绝"等可观测信号，攻击者就能借此推断目标内部的布尔状态，进而逐步拼出敏感数据。

工具链

文档收录了两个可直接用于 XS-Leak 研究的工具：

工具	定位
xsinator.com（RUB-NDS 出品）	XS-Leak 浏览器测试套件（Browser Test Suite），内置数十种已知 Oracle 的在线测试页面，是验证各浏览器行为差异的标准环境
AutoLeak（RUB-NDS 出品）	通过对两种状态下 DOM-Graph 做 diff来自动化发现浏览器中的 XS-Leak，适合批量审计与回归测试

方法论：从攻击原语到 XS-Search

攻击原语（Attack Primitives）

XS-Leak 的利用核心是找到"可观测的浏览器行为"。文档将其归纳为六类攻击原语：

原语（Primitive）	可泄漏的信息（Leaks）
Timing（时序）	资源大小 / 处理复杂度
Frame count（帧计数）	页面内容差异
Errors（错误事件）	访问控制决策（如 CORS、CORB 拦截）
Cache（缓存）	用户此前的访问历史
Navigation（导航）	认证状态（如是否登录后跳转不同）
Rendering（渲染）	文本长度（通过布局/滚动/字体加载推断）

每个原语本质上都在回答一个布尔问题（"这个页面是否包含 X？""这个用户是否登录？"），而多个布尔答案组合起来就能还原出完整信息。这一思想与 CSS Injection/README.md 中"用选择器/字体逐字符探测"的盲注思路同源——都是把不可读内容转化为可观测信号。

XS-Search：布尔 Oracle 逐字符爆破

XS-Search是 XS-Leak 最经典的攻击范式，专门针对基于查询的搜索系统（Query-Based Search Systems）。其思路是：

攻击者构造一个特定搜索词（如 flag 的前缀猜测）；
通过测量搜索请求的副作用——响应时间、frame 数量、错误事件等——判断该搜索"是否有返回结果"；
把"有结果 / 无结果"当作一个布尔 Oracle，逐字符爆破敏感数据。

文档给出了一个典型实例：

打开 50 个标签页，利用搜索结果页中iframe 的 CSP 违规（CSP violation）产生的时序差异，逐字符爆破 flag。

这个例子的关键在于：当搜索结果存在时，结果页会加载某个受 CSP 限制的 iframe，触发违规事件并带来可测量的时间差；攻击者开 50 个标签页做并行统计，把单次测量的噪声平均掉，从而稳定区分"命中/未命中"。其原理与 XSS Injection/4 - CSP Bypass.md 中利用 CSP 违规事件做探测的思路一脉相承——CSP 违规事件本身就是浏览器暴露给跨站观察者的信号源。

跨站 Oracle（Cross-site Oracles）

时序攻击（Timing Attacks）

时序攻击通过观察系统对特定请求的响应耗时来推断敏感信息。攻击者会向目标应用投递精心构造的脚本，执行 API 调用、发送 AJAX 请求、或发起跨域资源共享（CORS）交互，然后测量并比较这些操作的响应时间，从而推导系统内部行为、数据校验过程或底层安全控制的差异。

在 XS-Leak 场景下，时序差异通常来自：

搜索结果页的规模差异（命中时返回更多/更大的资源）；
服务端条件分支的处理耗时（如是否命中某条数据库记录）；
被 CSP / CORB 拦截的资源加载行为差异。

帧计数（Frame Counting）

如果目标页面根据用户状态（例如搜索结果的有无）会加载不同数量的 iframe，攻击者就可以通过计数来推断数据。文档给出的 PoC 如下：

// Get a reference to the window var win = window.open('https://example.org'); // Wait for the page to load setTimeout(() => { // Read the number of iframes loaded console.log("%d iframes detected", win.length); }, 2000);

关键点：window.open返回的引用允许读取win.length（子 frame 数量），而同源策略并不阻止读取 frame 数量。这与 Clickjacking/README.md 中攻击者对 iframe 的操控互为镜像——一个用 frame 做 UI 重定向，一个用 frame 做信息度量。

缓存探测（Cache Probing）

缓存探测攻击的目标是判断目标站点的某个特定资源是否已存在于受害者浏览器缓存中。攻击者让浏览器请求一个"只有已认证用户或已访问过某页面才会被缓存"的资源（图片、脚本或端点），然后：

测量该资源加载的快慢（命中缓存 vs 回源加载），或
观察缓存/非缓存响应之间的行为差异（例如第二次请求是否触发网络流量），

即可推断受害者是否满足某个条件（如是否登录过、是否访问过某页面）。

已知 Oracle 全集

文档收录了 xsinator.com 测试套件中 40+ 种已知 Oracle，按探测对象整理如下（测试页面均可在 xsinator.com 中在线验证）：

缓存 / 存储类

Cache Leak (CORS)：利用 CORS 错误删除缓存，探测页面加载了哪些资源；
Cache Leak (POST)：用 POST 请求删除缓存条目，探测页面资源加载情况；
Disk cache grooming：通过磁盘缓存梳理（grooming）技术构造可预测的缓存状态。

帧 / 导航 / 跳转类

ContentDocument X-Frame Leak：通过contentDocument探测X-Frame-Options；
Frame Count Leak：探测页面上的 iframe 数量；
COOP Leak：用 popup 探测Cross-Origin-Opener-Policy响应头；
CORS Error Leak：利用 CORS 错误泄漏重定向目标 URL；
CSP Redirect Detection / CSP Violation Leak：用 CSP 违规事件检测跨源重定向、泄漏重定向目标；
Fetch Redirect Leak：用 Fetch API 检测 HTTP 重定向；
Redirect Start Leak：通过检查redirectStart时间检测跨源 HTTP 重定向；
Duration Redirect Leak：通过检查耗时检测跨源重定向；
Max Redirect Leak：滥用最大重定向次数限制探测服务端重定向；
URL Max Length Leak：滥用 URL 最大长度限制探测服务端重定向；
History Length Leak：用 History API 检测 JavaScript 重定向。

资源加载 / 网络层类

CORB Leak：利用 CORB（Cross-Origin Read Blocking）结合特定 Content-Type 检测X-Content-Type-Options；
CORP Leak：用 fetch 检测Cross-Origin-Resource-Policy响应头；
Performance API CORP Leak：用 Performance API 检测 CORP 头；
Performance API Download Detection：用 Performance API 检测Content-Disposition下载响应；
Performance API Empty Page Leak：用 Performance API 检测空响应；
Performance API Error Leak：用 Performance API 检测加载错误；
Performance API X-Frame Leak：用 Performance API 检测X-Frame-Options；
Performance API XSS Auditor Leak：用 Performance API 检测页面中存在的脚本/事件处理器；
Download Detection：检测Content-Disposition头触发的下载行为；
ETag header length：通过 ETag 头长度检测响应体大小（2025 年新公开的技术）；
SRI Error Leak：利用 SRI（Subresource Integrity）校验错误泄漏内容长度；
Request Merging Error Leak：利用请求合并行为检测错误；
Style Reload Error Leak：利用样式表重载缺陷检测错误；
WebSocket Leak (FF / GC)：通过耗尽 WebSocket 连接数上限，探测页面上的 WebSocket 数量（分别针对 Firefox 与 Chrome/GC）。

DOM / CSS / 媒体类

CSP Directive Leak：用 CSP iframe 属性探测 CSP 指令；
CSS Property Leak：用getComputedStyle泄漏 CSS 规则；
Id Attribute Leak：用onblur泄漏可聚焦 HTML 元素的 id 属性（对应 PortSwigger 研究员 Gareth Heyes 的经典研究"Leaking IDs using focus"）；
Media Dimensions Leak：泄漏图片或视频的尺寸；
Media Duration Leak：泄漏音频或视频的时长；
MediaError Leak：通过 MediaError 消息检测 HTTP 状态码；
Payment API Leak：检测另一个标签页是否正在使用 Payment API；
Event Handler Leak（Object / Script / Stylesheet）：分别用<object>、<script>、样式表的onload/onerror检测加载错误。

防御视角：让 Oracle 无从观测

虽然 XS-Leak 的探测手段五花八门，但它们观测的信号大多对应着明确的安全响应头与浏览器策略。从文档的 Oracle 列表反推，可以得到一份清晰的加固清单：

限制帧嵌入：X-Frame-Options: DENY/SAMEORIGIN或 CSPframe-ancestors 'self'可阻断 ContentDocument X-Frame Leak、Performance API X-Frame Leak 等帧类探测；具体配置示例见 Clickjacking/README.md 的"Preventive Measures"章节（如Header always append X-Frame-Options SAMEORIGIN与<meta http-equiv="Content-Security-Policy" content="frame-ancestors 'self';">）。
收紧跨源读取策略：正确配置Cross-Origin-Opener-Policy（COOP）、Cross-Origin-Resource-Policy（CORP）、X-Content-Type-Options: nosniff，可削弱 COOP Leak、CORP Leak、CORB Leak、Performance API CORP Leak 等一族探测。
消除时序与大小侧信道：搜索类接口对"命中/未命中"返回等长、等时的响应，避免响应体大小或处理耗时随数据内容变化；同时评估接口的缓存策略，避免把认证状态烙进可被跨站探测的缓存条目。
合理设计 CSP：既要避免unsafe-inline等弱配置（绕过手法见 XSS Injection/4 - CSP Bypass.md），也要意识到 CSP 违规事件本身可能被 XS-Search 用作信号源——这需要结合产品形态权衡。

实战排查清单

在 Bug Bounty 或 CTF 中面对"响应体不可读"的目标时，可按以下顺序排查 XS-Leak 面：

枚举搜索/查询类接口：是否存在基于查询的搜索系统？其"有无结果"是否反映在加载帧数、响应时间或错误事件上（对应 XS-Search）？
测试六类攻击原语：依次验证 Timing、Frame count、Errors、Cache、Navigation、Rendering 六类可观测行为，确认哪一类在目标上成立（对应 Attack Primitives）。
对照已知 Oracle 清单逐项验证：将目标的响应头、资源加载行为与已知 Oracle 全集逐项比对，看哪些 Oracle 可用（例如目标未设 CORP 头即可尝试 CORP Leak）。
用工具批量验证：借助 xsinator.com 测试套件确认当前浏览器版本的行为差异，再用 AutoLeak 对目标做 DOM-Graph diff，发现自动化盲区。
组合布尔 Oracle 逐字符爆破：确认某个布尔 Oracle 稳定后，按 XS-Search 范式编写逐字符爆破脚本（参考文档"打开 50 个标签页利用 CSP 违规时序"的并行统计思路）。

练习靶场与参考资料

练习靶场：文档收录的 Root Me - XS Leaks 是 Web-Client 方向的专门练习（外部站点，仅作实践指引）。
CTF 案例（文档收录）：
- justCTF 2022 - Baby XSLeak Write-up（aszx87410，2022-06）；
- Facebook CTF 2019 - Secret Note Keeper（xs-leaks）（Abdillah Muhamad，2019-07）；
- SekaiCTF 2023 - Leakless Note（Kalmarunionen，2023-09）；
- HackTM Secrets - Exfiltration of secrets using an XS-Leaks（xanhacks，2023-02）；
- ASIS CTF Finals 2024 - web/fire-leak（arkark，2024-12）；
- SECCON CTF 14 Quals 2025 Web Challenges Writeup - RewriteLab（2025-12）；
- SECCON 2025 Quals - Impossible Leak（parrot409，2025-12）。
研究资料（文档收录）：Cross-Site ETag Length Leak（Takeshi Kaneko，2025-12）；XS-Leak: Leaking IDs using focus（Gareth Heyes / PortSwigger Research，2019-10）。

仓库内延伸阅读

XS-Leak/README.md：本文核心文档，含攻击原语表、XS-Search 说明与 Known Oracles 完整清单；
CORS Misconfiguration/README.md：CORS 错误/反射是多种 XS-Leak Oracle 的底层机制，可与 Cache Leak (CORS)、CORS Error Leak 对照学习；
Clickjacking/README.md：X-Frame-Options、CSPframe-ancestors等帧控制配置，是帧类 Oracle 的对抗面；
CSS Injection/README.md：CSS 选择器、@font-face unicode-range、attr()等盲注手法，与 Rendering 原语及 CSS Property Leak 直接相关；
XSS Injection/4 - CSP Bypass.md：CSP 绕过与 CSP 违规事件的利用，与 CSP Violation Leak、CSP Directive Leak 互为攻防。