第97篇 AI全栈 · 我研究了 100 多份 SSRF 报告

原创

陈看山
陈看山

安全诸子

2026年10月8日 20:38
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

可能是 Web 安全领域最容易被低估的漏洞之一。它不像 SQL 注入那样能直接拿到数据，也不像 RCE 那样能直接控制服务器，但它的危害半径往往超出预期——从内网端口扫描到云元数据窃取，从横向移动到供应链攻击。为了搞清楚这个漏洞在实际场景中到底怎么被打、怎么被防，我花了相当长的时间系统梳理了 100 多份公开的 SSRF 漏洞报告、Writeup 和 CVE 分析。这篇文章不是对 SSRF 基础概念的复述，而是想回答一个更具体的问题：在真实的漏洞报告里，SSRF 最常藏在哪里，又是怎么被绕过防御的？

这份调研到底在回答什么问题 网上关于 SSRF 的资料不少，但大多是讲原理、讲 payload，真正基于大量真实案例做归纳的内容并不多

我研究这 100 多份 SSRF 报告，核心是想搞清楚三件事： 第一，SSRF 的入口点分布。哪些功能模块最容易出现 SSRF？是 URL 导入、文件上传、还是回调接口？知道这些，企业做代码审计时就能有的放矢，安全测试人员也能更快锁定可疑点。 第二，过滤器绕过手法的实际使用频率。很多文章会列出几十种绕过技巧，但在真实攻击中，哪些手法真正被用上了？哪些只是理论上可行、实战中很少见到？ 第三，漏洞报告中最常见的失败原因。为什么有些 SSRF 报告被厂商标记为 N/A 或忽略？是只报了 DNS 回显、还是没证明实际影响？这些案例能帮漏洞猎人少走弯路。 需要说明的是，基于当前可见信息，这 100 多份报告主要来自 HackerOne、Bugcrowd 公开披露、以及安全研究者的个人博客。样本偏向于已被确认的漏洞，不代表所有 SSRF 的真实分布，但足够看出趋势。

评估维度

看一份 SSRF 报告到底该关注什么 为了系统梳理这 100 多份报告，我建立了一套分析框架。看一份 SSRF 漏洞报告，不能只看“能不能访问 localhost”就完事，至少要从下面几个维度去拆解。 入口类型对应的是漏洞触发点。是用户直接提交 URL，还是通过文件解析、跳转逻辑间接触发？这决定了漏洞的利用难度和影响范围。 数据回显方式决定了漏洞的可利用性。是完全回显、部分回显、盲打（Blind），还是只能通过带外（OAST）方式感知？回显方式直接影响危害评级。 目标可达性要看能访问到什么范围。是仅限本机回环、内网网段，还是能进一步访问云元数据服务（如 169.254.169.254）？这决定了 SSRF 能造成多严重的后果。 绕过复杂度则反映了防御的强度。目标有没有做 IP 黑名单、DNS 解析校验、协议限制？绕过手法是简单的 IP 变形，还是需要结合 DNS Rebinding、开放重定向等更复杂的技巧？ 报告结论是最后要看的——厂商最终怎么评级、怎么修复。这能反过来验证前面几个维度的判断是否准确。

入口点分布

真实报告里 SSRF 最常藏在哪里 把这 100 多份报告按入口类型归类后，分布情况比较清晰。URL 导入/抓取功能是最常见的入口，占比接近四成。这类功能通常表现为“通过 URL 导入图片”“远程拉取文件”“RSS 订阅抓取”等，开发者需要用户提供一个链接，然后用后端去请求这个链接，如果没做严格校验，就直接变成 SSRF 了。 文件上传与解析是第二大类，占比约两成。这里说的不是直接传一个恶意文件，而是上传的内容会被后端解析或处理。比如上传 PDF、SVG、Office 文档，后端用库去渲染或提取内容时，文件内部嵌入的外部资源链接就可能被请求。有一个典型案例是 PDF 中嵌入图片 URL，后端解析时就会去请求那个 URL。这类入口比较隐蔽，很多开发者根本没意识到文件解析过程会发起网络请求。 回调与 Webhook 配置是第三大类。一些应用允许用户配置回调地址或 Webhook URL，服务器在特定事件发生时向该地址发送请求。如果这个地址没有经过验证，就等于给了攻击者一个任意请求的入口。 代理与转发功能也有不少案例。应用本身提供代理功能，或者内部存在请求转发逻辑，用户可控的 URL 被服务器去请求。这类入口如果对协议不做限制，甚至可以利用 Gopher 协议去打 Redis 或内网其他服务。 无头浏览器渲染相关报告占比不高但影响严重。这类场景通常出现在“URL 转 PDF”“网页截图预览”等功能中，后端用无头浏览器访问用户提供的 URL，如果页面里包含内网地址或 file:// 协议的引用，无头浏览器就会去请求。这类 SSRF 往往能拿到内网页面的渲染结果，信息泄露比较直接。 剩下的零散入口包括图片处理库的远程加载、服务器状态监控面板、第三方集成（如云存储、社交媒体抓取）等。从这 100 多份报告来看，凡是后端需要根据用户输入去发起网络请求的地方，都有可能出现 SSRF，只是暴露程度不同。

过滤器绕过

真实案例里哪些手法被反复使用 绕过防御是 SSRF 报告里技术含量最高的部分。我统计了这 100 多份报告里出现的绕过手法，发现有几类出现频率明显更高。 IP 地址变形是使用最多的基础手法。很多应用只拦截了 127.0.0.1 和 localhost，但没拦住 127.1、0177.0.0.1（八进制）、2130706433（十进制整数形式）、0x7f000001（十六进制）。这些变体在真实报告里反复出现，说明很多开发者对 IP 的多种表示形式缺乏认知。还有不少案例用了 IPv6 的 ::1 或者 IPv4 映射地址 ::ffff:127.0.0.1，如果应用只做了 IPv4 的黑名单，这类地址就能直接穿透。 利用解析差异是更高级的绕过思路。同一段 URL，用 Python 的 urllib 解析和用 Go 的 net/url 解析可能得到不同的结果。比如 http://[email protected]，有的解析器认为是访问 evil.com，有的解析器认为是访问 127.0.0.1。还有 http://evil.com#@127.0.0.1 这类写法，不同语言对 fragment 和 host 的识别顺序不一样。报告中利用这类解析差异成功绕过的案例不少，而且往往是因为后端用了多层校验——先用一个解析器判断 URL 是否合法，再用另一个解析器去实际发请求，两个解析器理解不一致就产生了绕过空间。 开放重定向是容易被忽视的绕过方式。如果目标应用自己就存在开放重定向漏洞，攻击者可以提交一个指向合法域名的 URL，该域名重定向到内网地址，后端跟随重定向后就访问到了内网。有报告专门提到，先找应用内的开放重定向端点，再配合 SSRF 使用，比直接构造内网 URL 更容易绕过黑名单。 DNS Rebinding 在真实报告中的出现频率比我预想的要高。原理不复杂：攻击者控制一个域名，第一次解析时返回公网 IP（通过校验），第二次解析时返回内网 IP（实际请求）。如果应用只对 URL 做一次 DNS 解析校验，但实际请求时又做了一次解析，就可能被绕过。有报告显示，利用 DNS Rebinding 还能配合浏览器同源策略，从内网 Web 应用窃取数据——这在某些场景下能把 SSRF 升级为更严重的信息泄露。 协议切换也是报告中常见的绕过手段。很多防御只拦 HTTP/HTTPS 协议，但应用本身可能支持 FTP、Gopher、Dict 等协议。有案例通过 Gopher 协议攻击内网 Redis，直接写定时任务拿到 shell。这类案例虽然数量不多，但危害极大，说明协议的校验必须做完整，不能默认只允许 HTTP。

误读最多的参数

DNS 回显不等于可利用 SSRF 梳理这 100 多份报告时，发现一个高频踩坑点：很多人把 DNS 回显直接当成 SSRF 漏洞提交，结果被厂商忽略或降级处理。 在漏洞赏金平台的实际评审中，仅收到一次 DNS 解析请求通常不足以证明 SSRF 可利用。DNS 回显只能说明服务器确实对攻击者控制的域名发起了解析请求，但这可能是因为应用本身有 DNS 预解析、邮件服务器反垃圾邮件检查、或者 CDN 节点探测等行为。厂商通常会要求提供更进一步的证据——比如 HTTP 请求回显、内网端口连通性证明、或者读取到了云元数据服务的响应内容。 从报告被忽略的案例来看，只报 DNS Pingback 的通过率很低。更有效的做法是：先通过 DNS 回显确认服务器会发起请求，然后立刻尝试用 HTTP 协议请求自己可控的服务器，看能否收到完整的 HTTP 请求。如果收到了，再尝试访问内网地址或云元数据接口，证明实际影响。记住，SSRF 的价值在于“服务器发起了非预期的请求”，而不只是“服务器解析了非预期的域名”。

盲 SSRF 的检测思路

从 100 多份报告里提炼出的方法 盲 SSRF 是指服务器发起了请求，但响应不会直接返回给攻击者。这类漏洞在报告中往往容易被低估，因为看不到直接输出，需要靠带外（OAST）技术来确认。 检测盲 SSRF 的核心思路是：让服务器去请求一个你能监控的地址，然后观察是否有请求到达。具体操作上，可以用 Burp Collaborator 或者自建的交互服务，把一段唯一的标识符放在 URL 里，提交给目标应用，然后等待回调。 但这里有一个关键教训：不要只用一个协议去测。有报告显示，同一个入口点用 HTTP 协议去测没有回调，换成 HTTPS 后就有回调了——因为服务器的出站策略可能只放行了 443 端口。还有案例是应用对 URL 做了协议白名单，但白名单里包含了 file://，结果攻击者用 file:///etc/passwd 直接读取了文件内容，虽然响应不直接回显，但可以通过错误消息差异来判断文件是否存在。 盲 SSRF 的利用链通常需要结合其他漏洞。比如先盲打发现内网某台机器开了 8080 端口，再结合一个内网应用的其他漏洞做横向移动。所以检测到盲 SSRF 后，不要急于提交报告，先花时间探测一下可达的内网范围，这往往能显著提升漏洞的严重等级。

不同入口点的真实取舍

一张表看懂判断标准 基于这 100 多份报告的梳理，我把不同入口点的判断方式整理成下表。这可以作为安全测试人员或开发人员自查的参考框架。 | 入口点 | 应该关注什么 | 常见误区 | 更合理判断方式 | |--------|-------------|---------|---------------| | URL 导入/抓取 | 是否对协议做白名单校验，是否解析了 URL 后再请求 | 只看是否拦截了 localhost | 用 IP 变形、重定向、解析差异多种方式测试 | | 文件上传解析 | 上传的文件格…