Bug Class Deep Dives on Crusader Research

绕过简单过滤器的 SSRF：URL 解析器混淆与元数据端点

Sun, 05 Jul 2026 00:00:00 +0000

服务端请求伪造是少数几类单个发现就能直接把云凭据交到你手上的漏洞。其原理简单到一句话就能说清——你让服务器去抓取一个你所控制的 URL——而几乎每一篇文章都止步于此，这也正是它们毫无用处的原因。那个教科书式的载荷，把 http://169.254.169.254/ 粘进一个 URL 输入框，早已被到处列入黑名单。SSRF 之所以在 2026 年仍是最高产的漏洞类型之一，并不是因为开发者忘了做过滤。而是因为他们的过滤器和他们的 HTTP 客户端对 URL 的读法不一样，而你就住在这道缝隙里。

一个 URL 允许列表本质上是在赌两段代码——校验器和抓取器——对你所请求的是哪个主机看法一致。它们几乎从不一致。现代 SSRF 就是找出一个能被它们读成两种含义的字符串的艺术。

头号漏洞：URL 解析器混淆

Orange Tsai 的《A New Era of SSRF》为大家一直在栽跟头的东西起了名字：一个基于某个 URL 库构建的校验器，和一个基于另一个 URL 库构建的 HTTP 客户端，把同一字符串解析成了不同的主机。校验器说"这指向 expected-host，允许通过。“客户端却连上了 169.254.169.254。按各自对一个含糊规范的读法来看，两者的行为都没错（RFC 3986 在这里确实留了不小的余地）。你要做的，只是找到那个能把它们拆分开的输入。

确切的载荷，以及每一个为什么能把解析器拆开：

http://expected-host@169.254.169.254/

Userinfo 混淆。@ 之前的一切都是 userinfo 组件；真正的主机在它之后。一个天真的校验器，如果只在字符串开头去抓主机，就会看到 expected-host 并放行。而 HTTP 客户端正确解析后，连上了 169.254.169.254，并把 expected-host 当作（被忽略的）用户名传了过去。

http://169.254.169.254#@expected-host/

片段花招。一个"通过在 @ 上切分来找主机"的校验器会从尾部抓到 expected-host。但 # 开启的是片段——它之后的一切都会被抓取器丢弃，抓取器连上的是 169.254.169.254。允许列表检查的是一个网络永远看不到的字符串。

http://expected-host\@169.254.169.254/

反斜杠分歧。浏览器和 Go 的 net/url 会把 \ 归一化为 /，所以对它们来说主机是 expected-host，其余是路径。而不归一化反斜杠的库，会把 expected-host\ 当作 userinfo，把 169.254.169.254 当作主机。校验器和抓取器从同一串字节里落到了不同的主机上。

用单包攻击拿下 Web 竞态条件漏洞

Sun, 05 Jul 2026 00:00:00 +0000

大多数文章告诉你，竞态条件是"检查（check）与使用（use）之间的一段时间窗口"。没错，但没用 —— 因为你的 race 攻击失败，原因并不是你没搞懂这个概念，而是这个窗口比互联网的精度还要小。

一个典型的 race 窗口 —— 应用读取 balance 与写入 balance - amount 之间的间隙 —— 以微秒到几毫秒计。而当你在同一瞬间发出两个 HTTP request 时，等它们到达服务器并被调度时，两者之间的抖动通常有 1 到 10 毫秒，跨公网还会更糟。于是你那些"同时"发出的 request 排成整齐的一小列到达，服务器一个一个地处理，上限保持不破，你便断定这个端点是安全的。它并不安全。你只是在服务器还没来得及表态之前，就先输给了网络抖动。

利用 Web race 的全部功夫，就是一场让 N 个 request 在同一瞬间到达的搏斗。赢下它，那个"无法利用"的上限就会在一击之间崩塌。

为什么最后字节同步始终差那么一点

那个老式的 HTTP/1.1 技巧 —— 最后字节同步 —— 能让你接近目标：开约 20 个连接，把每个 request除最后一个字节以外的部分都发出去，然后一起发出所有的最后字节。它管用，多年来一直是最先进的做法。但它有一个无法修复的缺陷：这些是 20 个独立的 TCP 连接。每个都有自己的拥塞窗口、自己的路径时延、自己的内核调度。即便扣住最后一个字节，到达时间仍会被抹开几毫秒 —— 足以让你错过一个微秒级的窗口。最后字节同步把千分之一的 race 变成大概十分之一。是好了，但仍不稳定，仍然是"只有从同区域的 EC2 机器上才复现得出来"。

single-packet attack：一个 packet，零抖动

改变这一切的原语在此，出自 James Kettle 的 Smashing the State Machine 研究。HTTP/2 在一个连接上多路复用多个 request。于是你不再去竞速 20 个连接，而是：

IDOR 藏在第二个标识符里:用双账号 Shadow Replay 发现 BOLA

Sat, 04 Jul 2026 00:00:00 +0000

每篇 IDOR 教程都给你同一套操作:找到 /api/orders/48210,把它改成 48211,看有没有 200。这套操作训练你去攻击那个应用最可能会检查的标识符。URL 路径里的主键,正是框架的 @authorize 注解所在之处、ORM 收窄查询之处、评审聚焦之处。它是诱饵。你 fuzz 它,拿到一堆 403,判定这个接口安全,然后径直从漏洞旁边走过。

因为漏洞几乎从不在你看得见的那个 ID 里。它在第二个标识符里——那个应用压根忘了它也是个标识符的东西。

路径里的 ID 是他们会检查的那个。漏洞藏在 request 携带的第二个标识符里——body 里的 account_id、header 里的 tenant、GraphQL 别名里的 id——那个没人为它写过授权规则的东西。

换的是次要标识符,不是路径

下面是有回报的那种形态。一个 request 会同时以两种方式框定一个对象:路径里的一个资源 ID,以及别处的一个所有权 ID——一个 JSON 字段、一个 header、一个隐藏的表单值。路径里的 ID 会被校验。所有权 ID 会被信任。

POST /api/v2/reports/generate HTTP/2
authorization: Bearer <attacker token>
content-type: application/json

{ "report_id": "attacker-owned-uuid",
  "account_id": 5561,          ← victim's account, not yours
  "format": "pdf" }

report_id 属于你,所以每一层资源级检查都干净利落地通过。但 account_id 决定的是报表包含谁的数据,而处理程序直接从 body 里读取它,根本没问你的会话是否有权访问账号 5561。路径原封不动。只改 account_id——或 org_id、tenant_id,或那个带外承载同一含义的 X-Account-Id header。这就是大多数 hunter 从不做的那一步,因为教程训练出了错误的条件反射。