从AllThingsSSRF到现代SSRF攻击：URL解析差异的攻防演进

最新推荐文章于 2026-07-31 10:32:29 发布

原创

最新推荐文章于 2026-07-31 10:32:29 发布 · 494 阅读

1. 项目概述：从AllThingsSSRF到现代攻击链的演变

如果你在Web安全领域摸爬滚打了一段时间，那么“SSRF”（服务器端请求伪造）这个词对你来说肯定不陌生。它就像一个藏在服务器内部的“内鬼”，能让攻击者利用服务器的网络权限，去访问那些本该被防火墙保护起来的内部系统。几年前，当我们谈论SSRF时，讨论的焦点往往是那些经典的绕过技巧：比如利用 @ 符号、 # 号、DNS重绑定，或者是一些畸形协议如 gopher:// 、 dict:// 。那时候，防御的思路也相对直接：配置严格的内网IP黑名单、过滤危险的协议头。

但安全攻防从来不是静态的。Orange Tsai（蔡政达）这位在安全界响当当的研究员，通过他在Black Hat等顶级会议上的分享，彻底刷新了我们对SSRF的认知。他带来的不是一两个新的绕过技巧，而是一整套基于“URL解析差异”的、全新的攻击范式。这就像以前我们以为锁好了前门和后窗就安全了，但Orange Tsai告诉我们，攻击者可以通过墙壁材料本身的缝隙钻进来——这个“缝隙”，就是不同URL解析库、不同编程语言、甚至同一语言不同组件之间，对同一个URL字符串理解上的微妙差异。

“AllThingsSSRF”这个项目或概念，正是这种前沿研究的集大成体现。它不再局限于零散的技巧，而是系统性地梳理了从URL输入开始，到最终网络请求发出，整个链条上所有可能被利用的“解析歧义点”。理解这些，对于今天的应用安全建设至关重要。无论是红队人员想要拓宽攻击面，还是蓝队防御者希望构建更坚固的防线，深入Orange Tsai所揭示的URL解析漏洞与现代SSRF攻击，都是一个无法绕开的必修课。这篇文章，我就结合自己的研究和实战经验，为你拆解这背后的核心逻辑、技术细节以及防御思考。

2. 核心原理：URL解析差异为何是SSRF的“黄金矿脉”

要理解现代SSRF攻击的进化，我们必须先抛弃“URL只是一个简单的字符串”这种固有观念。实际上，一个URL从被用户输入，到被后端应用解析，再到最终被底层网络库发起请求，中间可能经过多个“解释器”。每一层解释器都有自己的“方言”（解析规则），当它们对同一个字符串产生不同理解时，漏洞就产生了。

2.1 URL的标准与现实的“鸿沟”

理论上，我们有RFC 3986等标准文档来定义URL的格式。但现实是骨感的。不同的编程语言（如Python的 urllib 、 urllib3 ， PHP的 parse_url ， Java的 java.net.URL ， Go的 net/url ），不同的网络库（如 libcurl 、 requests ），甚至同一语言内用于不同目的的函数（比如用于路由解析的和用于发起请求的），它们的URL解析实现都存在细微差别。

Orange Tsai研究的核心，就是系统性地挖掘这些差异。举个例子，一个经典的差异点在于“权限部分”（authority）的识别。考虑这个URL： http://evil.com@10.0.0.1:8080 。它的“正确”解析应该是：用户信息为 evil.com ，主机为 10.0.0.1 ，端口为 8080 。服务器在发起请求时，应该连接到 10.0.0.1:8080 。但有些旧的解析器，或者某些上下文下的解析器，可能会将 evil.com 错误地解析为主机名。如果应用端用A解析器做校验（认为主机是 evil.com ，通过了外网校验），而底层请求库用B解析器做实际连接（连接到 10.0.0.1 ，即内网地址），一个SSRF漏洞就产生了。

注意：这里提到的“校验”和“连接”使用不同解析器的情况非常普遍。比如，Web框架的路由层或一个安全过滤函数用一套逻辑解析URL提取主机名进行校验，而业务代码中真正发起HTTP请求的 requests.get() 或 curl_easy_perform 用的是另一套底层库的逻辑。

2.2 关键差异点剖析

这些解析差异主要体现在以下几个维度，它们共同构成了攻击面：

URL编码与多重解码 ：这是最富饶的土壤。 %2f 是 / ， %252f 是经过两次URL编码后的 / （第一次编码 %2f ，第二次对 % 编码为 %25 ）。解析器A可能只解码一次，看到的是 %2f ，将其视为路径分隔符的一部分。而解析器B可能解码两次，最终看到的是 / ，这可能会完全改变URL的路径结构，甚至将路径部分“提升”为主机名的一部分。
特殊字符的歧义 ： @ 、 # 、 ? 、 \ 这些字符在URL的不同部分有特殊含义。 @ 用于分隔用户信息和主机， # 是片段标识符， ? 是查询字符串开始。但一些解析器在非标准位置遇到这些字符时，处理方式可能不同。例如，在主机名中出现 @ 符号，有的解析器会停止解析主机名，有的则会将其作为主机名的一部分。
协议处理器的切换 ：URL以 protocol:// 开头。但一些库支持“协议相对URL”（如 //example.com ），或者对某些协议有特殊处理逻辑（如 file:// 、 gopher:// ）。攻击者可能通过构造 http://example.com#@evil.com 这样的Payload，利用片段标识符的解析差异，让某个解析器看到的是 example.com ，而另一个解析器实际请求的却是 evil.com 。
主机名解析的边界 ：什么是有效的主机名？ 10.0.0.1 是IP，