绕过简单过滤器的 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 当作主机。校验器和抓取器从同一串字节里落到了不同的主机上。

Oast on Crusader Research

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

头号漏洞：URL 解析器混淆