一个在深入研究了 100 多篇有关服务器端请求伪造 (SSRF) 的文章和报告后，我将我获得的关键见解和知识汇编到此博客中。在这里，我旨在分享有关 SSRF 漏洞的全面概述

服务器端请求伪造（SSRF）

服务器端请求伪造 (SSRF) 是一种漏洞，允许攻击者从易受攻击的服务器向其他内部或外部资源发送精心设计的请求。当 Web 应用程序接受来自用户的 URL 或 IP 地址输入并使用该输入发出请求而未对其进行适当验证或清理时，就会发生 SSRF。

识别 SSRF 漏洞

识别目标应用程序中的 SSRF 需要了解该应用程序如何与外部资源交互、处理 URL 以及处理用户输入。您要做的第一件事是退后一步，查看目标应用程序中获取外部资源的所有功能。这可能是从加载图像到从其他服务器获取数据的任何内容。这些点是最有可能出现 SSRF 漏洞的入口点。

URL 导入功能：常见的一种。考虑一下应用程序基于 URL 获取某些内容的功能 — 可能是图像导入器或数据获取器。如果应用程序从外部 URL 获取内容，那么可以肯定它可能容易受到 SSRF 攻击，尤其是在没有适当验证的情况下。这里的想法是尝试提供内部 URL，例如http://localhost或http://127.0.0.1

文件上传机制：是的，文件上传。这些可能很狡猾。想象一下一个允许用户上传文件的应用程序——比如 PDF、SVG 甚至 Office 文档。如果后端处理这些文件，SSRF 可能就藏在这里。您可以尝试上传带有指向内部服务的嵌入式 URL 的文件（参考：PDF 特洛伊木马：利用 HTML 注入进行 SSRF 和内部资源访问）。

无头浏览器/HTML 渲染：这些通常出现在后端生成 PDF 或图像的功能中。当您使用无头浏览器找到目标时，请尝试将 URL 注入处理 HTML 内容的区域。如果您设法让后端获取一些非预期的内容，您可能已经找到了 SSRF 金矿！（参考：无头浏览器上的 SSRF 变得至关重要）。

服务器状态和监控功能：现在，寻找那些允许您检查服务器状态或应用程序健康状况的功能。这些功能通常会查询内部服务以获取状态信息 - SSRF 的绝佳场所。如果您找到一个，请尝试操纵请求以访问内部端点或敏感服务（参考：Google Cloud 监控中的 31k SSRF）。

代理实现：代理很有趣，因为它们会通过服务器路由请求。如果应用程序允许您通过代理发送请求，并且不严格验证 URL，那么您就有可能遭受 SSRF 攻击。如果它不清理用户提供的 URL，情况尤其如此。尝试向内部服务或其他未经授权的端点发送请求，看看会发生什么（参考：Havoc C2 上的服务器端请求伪造）。

安全机制中的漏洞：不仅仅是应用程序本身——有时，SSRF 隐藏在应用程序使用的库和安全机制中。身份验证库、请求处理组件或其他后端工具可能存在 SSRF 漏洞。您也需要审核这些，因为这些第三方系统通常会暴露您意想不到的漏洞（参考：挖掘 Next.js 应用程序中的 SSRF）。

文件存储集成：如果您的目标与 Google Drive、Amazon S3 或 Dropbox 等第三方服务集成，请检查该应用是否发出服务器端请求来获取或存储文件。这些是 SSRF 的绝佳候选对象，因为您可以尝试操纵请求以从未经授权的服务中获取内部文件或数据。通过向这些集成中注入精心设计的 URL，您可能会访问从未打算公开的内部系统（参考：SSRF：价值 4,913 美元的服务器端请求伪造）。

路径参数和主机标头：密切关注路径参数和主机标头的处理方式。如果应用程序使用路径参数来构造服务器端请求，那么这是测试 SSRF 的另一个点。尝试操纵参数以将请求重定向到内部资源。同样，主机标头可能被用来控制请求的发送位置。在这里测试任何弱点——您可能能够使用主机标头影响请求的目的地（参考：主机标头注入以完成组织接管）。

盲目的 SSRF

盲 SSRF 是一种漏洞，您可以向内部主机发送请求，但只会收到响应中的状态代码，而不是完整的 HTTP 响应。

检测盲 SSRF 漏洞最可靠的方法是使用带外 (OAST) 技术。这涉及触发对您控制的外部系统的 HTTP 请求并监控与该系统的任何网络交互。

漏洞赏金猎人最常犯的错误之一是仅报告 DNS pingback。仅通过 Burp Collaborator 接收 DNS pingback 不足以确认 SSRF 漏洞。事实上，在大多数漏洞赏金平台上，DNS pingback 通常被认为超出了赏金范围。

使用 DNS 重新绑定的 SSRF

当 SSRF（服务器端请求伪造）和 DNS 重新绑定结合使用时，它们可以创建一个强大的攻击媒介。虽然这种组合并不常见，但它可以通过有效绕过同源策略而导致重大风险。这主要是因为从浏览器的角度来看，目标服务器和环回地址被视为同一域的一部分。

考虑以下场景：受害者正在使用工作笔记本电脑浏览互联网，该笔记本电脑连接到组织的网络。该网络中有一个内部 Web 应用程序，位于http://192.168.1.3/，仅在组织内可访问。

为了从该内部 Web 应用程序中窃取数据，攻击者可以利用 DNS 重新绑定，如下所示：

1. 域名获取：攻击者获取域名example.com，并配置一个具有较低生存时间 (TTL) 设置的 DNS 服务器。此 DNS 服务器设置为将example.com解析为托管恶意 JavaScript 负载的 Web 应用程序的 IP 地址。

2. 受害者互动：受害者通过http://example.com访问攻击者的 Web 应用程序。此时，浏览器将example.com解析为攻击者的服务器，并加载恶意 JavaScript 负载。

3. DNS 重新绑定：然后攻击者更新或“重新绑定” example.com的 DNS 设置以解析为内部 Web 应用程序192.168.1.3 。

4. 恶意请求：JavaScript 负载向http://example.com/sensitive-endpoint发起 HTTP GET 请求。由于 DNS 重新绑定，example.com现在解析为192.168.1.3。因此，受害者的浏览器将请求发送到内部 Web 应用程序。由于来源（即方案、主机和端口）保持不变，因此此请求不被视为跨源。因此，JavaScript 代码可以访问响应而不会违反同源策略。

5. 数据泄露：最后，JavaScript 负载将响应数据泄露到攻击者控制的另一个域，例如http://harmfull.example.com。

SSRF 过滤器绕过

绕过 SSRF（服务器端请求伪造）过滤器时，了解可用于规避保护的各种技术至关重要。以下是可用于绕过 SSRF 防御的几种有效方法：

开放重定向：这些重定向可以将请求重定向到原本被阻止的端点。可以利用目标应用程序中的开放重定向漏洞，通过将请求重定向到内部服务来绕过 SSRF 过滤器。

IP 地址技巧：一些 SSRF 保护会阻止特定主机（例如 localhost 或 127.0.0.1），但也有一些方法可以伪装这些 IP：

• 本地主机范围： 127.0.0.0至127.255.255.255

• 缩写形式： 127.1

• 填充形式： 127.000000000000000.1

• 全零：（ 0.0.0.0通常解析为本地机器）

• 缩短零：简单0

• 十进制形式： 2130706433

• 八进制形式： 0177.0000.0000.0001

• 十六进制形式： 0x7f000001

• IPv6 环回： 0:0:0:0:0:0:0:1或::1

• IPv4 映射的 IPv6 环回： ::ffff:127.0.0.1

基于协议的绕过：一些 SSRF 过滤器专注于阻止 HTTP(S) URL，但许多 Web 应用程序支持其他协议，如 FTP 或 SMTP。通过切换协议，您可能会访问过滤器未监控的受限资源。

IP 混淆技术：以不寻常的方式对 IP 地址进行编码或操作有助于绕过过滤器。这包括十六进制、八进制或十进制表示的 IP 地址，这些地址可能无法被简单的过滤规则识别。

URL 编码和解析技巧：许多 SSRF 过滤器都难以处理不常见或编码的 URL 格式。如果过滤器无法彻底规范或验证 URL，尝试使用 URL 编码、双重编码或添加空字节可能会有所帮助。

使用不同的解析器：通过测试目标应用程序中的不同解析器如何解释 URL，您可以识别允许访问被阻止端点的不一致之处。

有关 SSRF 有效负载的详细参考，请查看PayloadsAllTheThings GitHub 存储库。

SSRF 的实用工具

SSRFmap,自动 SSRF 模糊测试和开发工具,下载SSRFmap的源码_GitHub_帮酷

GitHub - knassar702/lorsrf：快速 CLI 工具，用于查找可用于查找 SSRF 或……的参数

GitHub - blackhatethicalhacking/SSRFPwned：使用内置自定义有效负载检查 SSRF……

GitHub - Th0h0/autossrf：基于智能上下文的 SSRF 漏洞扫描程序。

GitHub - vysecurity/IPFuscator：IPFuscator - 一种自动生成替代 IP 的工具……

GitHub - mogwailabs/DNSrebinder：一个基于 Python 的最小 DNS 服务器，用于测试/验证 DNS 重新绑定……

原文始发于微信公众号（星空网络安全）：我研究了 100 多份 SSRF 报告