【Academy】SSRF ------ Server-side request forgery

概述
本文将解释什么是服务器端请求伪造 （SSRF），并介绍一些常见示例。还向您展示了如何查找和测试 SSRF 漏洞，以及如何防御 SSRF。

1. 什么是 SSRF？

服务器端请求伪造是一种 Web 安全漏洞，它允许攻击者使服务器端应用程序向意外位置发出请求。

在典型的 SSRF 攻击中，攻击者可能会导致服务器连接到组织基础设施中的仅限内部的服务。在其他情况下，它们可能能够强制服务器连接到任意外部系统。这可能会泄露敏感数据，例如授权凭证。

2. SSRF 攻击的影响是什么？

成功的 SSRF 攻击通常会导致未经授权的操作或访问组织内的数据。这可能位于易受攻击的应用程序中，也可能位于应用程序可以与之通信的其他后端系统上。在某些情况下，SSRF 漏洞可能允许攻击者执行任意命令。

导致连接到外部第三方系统的 SSRF 漏洞可能会导致恶意的后续攻击。这些可能看起来来自托管易受攻击的应用程序的组织。

3. 常见的 SSRF 攻击

服务端请求伪造（Server-Side Request Forgery，SSRF）攻击通常利用信任关系，从易受攻击的应用程序扩大攻击范围并执行未经授权的操作。这些信任关系可能存在于与服务器的关系中，或者与同一组织内的其他后端系统的关系中。

3.1 针对服务器的 SSRF 攻击

在针对服务器的服务端请求伪造（SSRF）攻击中，攻击者使应用程序通过其回环网络接口向托管该应用程序的服务器发出 HTTP 请求。这通常涉及提供一个带有主机名的 URL，例如127.0.0.1（指向回环适配器的保留 IP 地址）或localhost（同一个适配器的常用名称）。

例如，想象一个购物应用程序，它允许用户查看特定商店中的商品是否有库存。为了提供库存信息，应用程序必须查询各种后端 REST API。它通过前端 HTTP 请求将 URL 传递到相关的后端 API 端点来实现这一点。当用户查看商品的库存状态时，他们的浏览器会发出以下请求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

这会导致服务器向指定的 URL 发出请求，检索常用状态，并将其返回给用户。

在此示例中，攻击者可以修改请求以指定服务器本地的 URL：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

服务器获取 /admin URL 的内容并将其返回给用户。

攻击者可以访问 /admin URL，但管理功能通常只有经过身份验证的用户才能访问。这意味着攻击者不会看到任何感兴趣的内容。但是，如果对 /admin URL 的请求来自本地计算机，则会绕过正常的访问控制。应用程序授予对管理功能的完全访问权限，因为请求似乎来自受信任的位置。

为什么应用程序以这种方式运行，并隐式信任来自本地计算机的请求？这可能是由于各种原因造成的：

• 访问控制检查可能在位于应用服务器前面的不同组件中实现。当建立与服务器的连接时，该检查会被绕过。
• 出于灾难恢复目的，应用程序可能允许来自本地机器的任何用户在不登录的情况下进行管理访问。这为管理员在丢失凭据的情况下恢复系统提供了一种方法。这是基于只有完全受信任的用户才会直接从服务器访问的假设。
• 管理界面可能在与主应用程序不同的端口号上进行监听，并且可能无法被用户直接访问。

在这种信任关系中，来自本地计算机的请求的处理方式与普通请求的处理方式不同，通常会使 SSRF 成为严重漏洞。

3.2 针对其他后端系统的 SSRF 攻击

在某些情况下，应用程序服务器能够与用户无法直接访问的后端系统进行交互。这些系统通常具有不可路由的私有 IP 地址。后端系统通常受网络拓扑保护，因此它们的安全状况通常较弱。在许多情况下，内部后端系统包含敏感功能，任何能够与系统交互的人都可以在不进行身份验证的情况下访问这些功能。

在前面的示例中，假设后端 URL https://192.168.0.68/admin 有一个管理界面。攻击者可以提交以下请求来利用 SSRF 漏洞，并访问管理界面：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

4. 规避常见的 SSRF 防御

通常可以看到应用程序中同时存在服务端请求伪造（SSRF）行为以及旨在防止恶意利用的防御措施。通常，这些防御措施可以被绕过。

4.1 具有基于黑名单的输入过滤器的 SSRF

某些应用程序会阻止包含主机名（如 127.0.0.1 和 localhost）或敏感 URL（如 /admin）的输入。在这种情况下，您通常可以使用以下技术来规避过滤器：

• 使用 127.0.0.1 的替代 IP 表示形式，例如 2130706433、017700000001 或 127.1。
• 注册您自己的域名，该域名解析为 127.0.0.1。您可以将 spoofed.burpcollaborator.net 用于此目的。
• 使用 URL 编码或大小写变体对被阻止的字符串进行混淆处理。
• 提供您控制的 URL，该 URL 将重定向到目标 URL。尝试对目标 URL 使用不同的重定向代码和不同的协议。例如，在重定向过程中从 http: 切换到 https: URL 已被证明会绕过某些反 SSRF 过滤器。

4.2 具有基于白名单的输入过滤器的 SSRF

某些应用程序只允许匹配允许值的白名单的输入。筛选器可能会在输入的开头查找匹配项，或者查找包含在输入中的匹配项。您可以通过利用 URL 解析中的不一致来绕过此过滤器。

URL 规范包含许多功能，当 URL 使用此方法实现临时解析和验证时，这些功能可能会被忽略：

• 您可以使用 @ 字符将凭证嵌入到主机名之前的 URL 中。例如：

https://expected-host:fakepassword@evil-host

• 您可以使用 # 字符来指示 URL 片段。例如：

https://evil-host#expected-host

• 您可以利用 DNS 命名层次结构将所需的输入放入您控制的完全限定 DNS 名称中。例如：

https://expected-host.evil-host

• 您可以对字符进行 URL 编码以混淆 URL 解析代码。如果实现筛选条件的代码处理 URL 编码字符的方式与执行后端 HTTP 请求的代码不同，则此功能特别有用。您还可以尝试双重编码字符;一些服务器以递归方式对他们收到的输入进行 URL 解码，这可能会导致进一步的差异。
• 您可以结合使用这些技术。

4.3 通过开放重定向绕过 SSRF 过滤器

有时可以通过利用开放重定向漏洞来绕过基于过滤器的防御。

在前面的示例中，假设用户提交的 URL 经过严格验证，以防止恶意利用 SSRF 行为。但是，允许其 URL 的应用程序包含开放重定向漏洞。如果用于发出后端 HTTP 请求的 API 支持重定向，您可以构建一个满足筛选条件的 URL，并将请求重定向到所需的后端目标。

例如，该应用程序包含一个开放重定向漏洞，其中以下 URL：

/product/nextProduct?currentProductId=6&path=http://evil-user.net

返回重定向到：

http://evil-user.net

您可以利用开放重定向漏洞绕过 URL 过滤器，并按如下方式利用 SSRF 漏洞：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

此 SSRF 漏洞之所以有效，是因为应用程序首先验证提供的 stockAPI URL 是否位于允许的域上，而事实确实如此。然后，应用程序请求提供的 URL，这将触发开放重定向。它遵循重定向，并向攻击者选择的内部 URL 发出请求。

5. 盲 SSRF 漏洞

如果您可以使应用程序向提供的 URL 发出后端 HTTP 请求，但后端请求的响应未在应用程序的前端响应中返回，则会出现盲目 SSRF 漏洞。

盲 SSRF 更难被利用，但有时会导致在服务器或其他后端组件上完全远程执行代码。

在本节中，我们将解释什么是服务器端盲请求伪造，描述一些常见的盲 SSRF 示例，并解释如何查找和利用盲 SSRF 漏洞。

什么是盲 SSRF？
当可以诱使应用程序向提供的 URL 发出后端 HTTP 请求，但后端请求的响应未在应用程序的前端响应中返回时，就会出现盲 SSRF 漏洞。

5.1 盲 SSRF 漏洞有什么影响？

由于其单向性，盲 SSRF 漏洞的影响通常低于完全知情的 SSRF 漏洞。它们不能被轻易地利用来从后端系统检索敏感数据，尽管在某些情况下可以利用它们来实现完全远程代码执行。

5.2 如何查找和利用盲 SSRF 漏洞

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

使用带外技术的最简单、最有效的方法是使用 Burp Collaborator。您可以使用 Burp Collaborator 生成唯一的域名，将这些域名发送到有效负载，并监控与这些域的任何交互。如果观察到来自应用程序的传入 HTTP 请求，则它容易受到 SSRF 的攻击。

注意
在测试 SSRF 漏洞时，通常会观察到对提供的协作者域的 DNS 查找，但没有后续的 HTTP 请求。这通常是因为应用程序尝试向域发出 HTTP 请求，这导致了初始 DNS 查找，但实际的 HTTP 请求被网络级过滤阻止。基础设施允许出站 DNS 流量是相对常见的，因为这样做有很多用途，但会阻止与意外目的地的 HTTP 连接。

简单地识别可能触发带外 HTTP 请求的盲 SSRF 漏洞本身并不能提供可利用的途径。由于您无法查看来自后端请求的响应，因此该行为不能用于浏览应用程序服务器可以访问的系统上的内容。但是，它仍可用于探测服务器本身或其他后端系统上的其他漏洞。您可以盲目扫描内部 IP 地址空间，发送旨在检测已知漏洞的有效负载。如果这些有效负载还采用盲带外技术，则您可能会在未修补的内部服务器上发现严重漏洞。

利用盲 SSRF 漏洞的另一种途径是诱使应用程序连接到攻击者控制下的系统，并将恶意响应返回给建立连接的 HTTP 客户端。如果您可以利用服务器的 HTTP 实现中的严重客户端漏洞，则可能能够在应用程序基础设施中实现远程代码执行。

6. 寻找 SSRF 漏洞的隐藏攻击面

许多服务器端请求伪造漏洞很容易被发现，因为应用程序的正常流量涉及包含完整 URL 的请求参数。服务器端请求伪造的其他示例则更难定位。

6.1 请求中的部分 URL

有时，应用程序仅将主机名或 URL 路径的一部分放入请求参数中。然后，提交的值将在服务器端合并到请求的完整 URL 中。如果该值很容易被识别为主机名或 URL 路径，则潜在的攻击面可能很明显。但是，作为完整 SSRF 的可利用性可能会受到限制，因为您无法控制请求的整个 URL。

6.2 数据格式中的 URL

一些应用程序以特定格式传输数据，该格式的规范允许包含可能被格式的数据解析器请求的 URL。一个明显的例子是 XML 数据格式，它在 Web 应用程序中被广泛用于将结构化数据从客户端传输到服务器。当应用程序接受 XML 格式的数据并进行解析时，它可能容易受到 XXE 注入攻击。它也可能通过 XXE 容易受到 SSRF 攻击。

6.3 通过 Referer 标头的 SSRF

一些应用程序使用服务器端分析软件来跟踪访问者。该软件通常会在请求中记录 Referer 标头，以便它可以跟踪传入的链接。通常，分析软件会访问 Referer 标头中显示的任何第三方 URL。这样做通常是为了分析引用网站的内容，包括传入链接中使用的锚文本。因此，Referer 标头通常是 SSRF 漏洞的有用攻击面。

7. 如何防御 SSRF

7.1 限制请求的目标范围

1. 基于IP地址的限制

   • 维护一个合法的IP地址白名单。只允许服务器向在白名单中的IP地址发起请求。例如，在配置文件中明确列出内部服务的IP地址段，如192.168.1.0/24用于内部数据库服务器的访问。当有请求发起时，检查目标IP是否在这个白名单范围内。
   • 对于互联网服务，可以限制对知名的、经过认证的第三方服务提供商的IP地址进行访问。如支付网关的固定IP段，防止请求被伪造到恶意的IP地址。

2. 基于域名的限制

   • 同样建立一个可信域名的白名单。通过配置服务器的DNS解析，确保请求的域名解析后的IP地址是在预期范围内。例如，只允许向自己公司的官方合作伙伴域名（如partnercompany.com）发起请求，并且定期检查这些域名的解析记录是否被篡改。
   • 可以使用域名系统安全扩展（DNSSEC）来验证域名解析的完整性和真实性，防止攻击者通过篡改DNS记录将请求重定向到恶意服务器。

3. 限制端口范围

   • 明确指定允许访问的端口。对于大多数应用，只需要访问特定的几个端口，如HTTP服务的80端口、HTTPS服务的443端口等。限制服务器只能向这些指定端口发起请求，避免向一些可能被利用的敏感端口（如数据库默认端口3306等）发送请求。
   • 例如，在网络代理设置中，配置只允许通过端口80和443进行外部连接，对于其他端口的请求进行拦截和记录。

7.2 验证用户输入

1. 输入格式检查
   • 对用户输入的URL或其他可能用于请求的参数进行严格的格式检查。例如，确保输入的URL符合标准的URL格式（如使用正则表达式来验证是否包含正确的协议头http://或https://，以及合法的域名和路径部分）。
   • 对于不符合格式要求的输入，直接拒绝并返回错误信息。例如，如果用户输入的URL缺少协议部分或者包含非法字符（如控制字符），就判定为非法输入。
2. 过滤敏感信息
   • 检查用户输入中是否包含内部网络的IP地址、敏感的域名或其他可能导致SSRF攻击的信息。例如，过滤掉包含本地回环地址（如127.0.0.1）、私有IP地址段（如10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）等内容。
   • 还可以过滤掉可能指向内部管理接口的特定路径，如/admin或/internal-api等，防止攻击者通过SSRF访问这些内部敏感资源。

7.3 安全的网络配置和架构设计

1. 使用独立的网络环境和代理
   • 将对外请求的服务器放置在独立的网络区域，通过代理服务器进行请求转发。代理服务器可以对请求进行额外的安全检查和过滤，例如检查请求的合法性、记录请求日志等。
   • 例如，在企业网络中，将面向互联网的Web服务器和内部应用服务器之间设置防火墙和代理，Web服务器通过代理向内部服务器请求数据，代理可以限制请求的流向和内容。
2. 采用微服务架构的安全策略
   • 在微服务架构中，每个服务之间的通信可以采用安全的通信协议，如TLS加密。并且可以在服务注册和发现机制中添加安全验证，防止未经授权的服务访问。
   • 例如，服务A需要访问服务B，服务A在向服务注册中心请求服务B的地址时，需要进行身份验证，服务注册中心也会验证服务A是否有访问服务B的权限，这样可以避免恶意服务通过SSRF攻击获取服务B的信息。

7.4 监控和审计

1. 请求日志记录
   • 详细记录服务器发起的所有外部请求，包括请求的URL、请求时间、请求源等信息。通过分析日志，可以及时发现异常的请求模式，如频繁请求到非法的IP地址或域名。
   • 例如，设置日志记录系统，记录每次请求的详细信息，当出现安全事件时，可以通过查询日志来追踪攻击路径和攻击者可能利用的漏洞。
2. 异常检测系统
   • 建立异常检测机制，通过分析请求的流量、频率、目标等特征来识别可能的SSRF攻击。例如，如果发现服务器突然向大量不同的未知IP地址发起请求，或者请求的频率超出正常范围，就触发警报。
   • 可以使用机器学习算法来建立请求行为的基线模型，当实际请求行为偏离基线时，判定为异常情况并进行进一步的调查。