做一个有温度和有干货的技术分享作者 —— Qborfy
背景
最近在研究SSR，发现很多服务都会用到SSRF，所以就顺便研究了一下SSRF。
下面是一篇从网络上翻译过来的文章， 大家简单参考了解。
什么是 SSRF？
服务器端请求伪造是一种 Web 安全漏洞，允许攻击者导致服务器端，从而发出非法请求。
在典型的 SSRF 攻击中，攻击者可能会导致服务器连接到仅供内部使用的服务。在其他情况下，他们可能能够强制服务器连接到任意外部系统。这可能会泄露敏感数据，例如授权凭据。
SSRF攻击的危害
SSRF 攻击通常会导致未经授权的操作或组织内的数据访问。这可能位于易受攻击的网站中，也可能位于该网站可以与之通信的其他后端系统上。在某些情况下，SSRF 漏洞可能允许攻击者执行任意命令。
与外部第三方系统连接，如：接入第三方的登录等， 更容易受到SSRF漏洞攻击。
常见的SSRF攻击
SSRF 攻击通常利用信任关系， 去攻击的网站， 并执行未经授权的操作。这些信任关系可能与服务器相关，或者与同一组织内的其他后端系统相关。
针对服务器的 SSRF 攻击
在针对服务器的 SSRF 攻击中，攻击者会通过内部络接口向网站的服务器发出 HTTP 请求。这通常涉及提供带有主机名的 URL，例如127.0.0.1 或localhost。
例如，想象一个购物网站，它允许用户查看特定商店中是否有商品的库存。为了提供信息，网站必须查询各种后端 REST API。它通过前端 HTTP 请求将 URL 当成参数传递到后端，然后执行 API 端点来实现此目的。当用户查看商品的库存状态时，他们的浏览器会发出以下请求：
1 | POST /product/stock HTTP/1.0 |
这会导致服务器向指定的 URL 发出请求，检索库存状态，并将其返回给用户。
在此示例中，攻击者可以修改请求以指定服务器本地的 URL：
1 | POST /product/stock HTTP/1.0 |
服务器获取/admin URL 的内容并将其返回给用户。
攻击者可以访问/admin URL，但管理功能通常只有经过身份验证的用户才能访问。这意味着攻击者不会看到任何感兴趣的内容。但是，如果对/admin URL 的请求来自本地计算机，则会绕过正常的访问控制。应用程序授予对管理功能的完全访问权限，因为请求似乎源自受信任的位置。
为什么应用程序会以这种方式运行，并隐式信任来自本地计算机的请求？出现这种情况的原因有多种：
- 鉴权控制只在前端网关层控制，却没有在服务器上做任何限制。
- 出于容灾设计，允许来自本地的任何用户无需登录即可进行管理访问，只有完全信任的用户会直接来自服务器。
- 后管系统与用户系统用不同的端口号，并且用户可能无法直接访问。
这种信任关系（其中源自本地计算机的请求的处理方式与普通请求不同）通常使 SSRF 成为严重漏洞。
针对其他后端系统的 SSRF 攻击
在某些情况下，应用程序服务器能够与用户无法直接访问的后端系统进行交互。这些系统通常具有不可访问的专用 IP 地址。后端系统通常受到网络拓扑的保护，因此它们的安全状况通常较弱。在许多情况下，内部后端系统包含敏感功能，任何能够与系统交互的人都可以在无需身份验证的情况下访问这些功能。
在前面的示例中，假设后端 URL https://192.168.0.68/admin 有一个管理界面。攻击者可以提交以下请求来利用SSRF漏洞，并访问管理界面：
1 | POST /product/stock HTTP/1.0 |
规避常见的 SSRF 防御
包含 SSRF 行为以及旨在防止恶意利用的防御措施的应用程序很常见。通常，这些防御措施是可以被规避的。
具有基于黑名单的输入过滤器的 SSRF
某些应用程序会阻止包含主机名（如127.0.0.1和localhost或敏感 URL（如/admin的输入，可如下设计：
- 使用替代 IP 表示形式127.0.0.1 ，例如2130706433 、 017700000001或127.1等，作为超管系统等别名。
- 注册您自己的域名，解析为127.0.0.1 。您可以使用spoofed.burpcollaborator.net来实现此目的。
- 使用 URL 编码或大小写变化来混淆被阻止的字符串。
- 提供您控制的 URL，该 URL 会重定向到目标 URL。尝试对目标 URL 使用不同的重定向代码以及不同的协议。例如，在重定向过程中从http:切换到https: URL 已被证明可以绕过某些反 SSRF 过滤器。
具有基于白名单的输入过滤器的 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 解码，这可能会导致进一步的差异。
- 您可以结合使用这些技术。
通过开放重定向绕过 SSRF 过滤器
有时可以通过利用开放重定向漏洞来绕过基于过滤器的防御。
在前面的示例中，假设用户提交的 URL 经过严格验证，以防止恶意利用 SSRF 行为。但是，允许 URL 的应用程序包含开放重定向漏洞。如果用于发出后端 HTTP 请求的 API 支持重定向，您可以构造一个满足过滤器的 URL，并将请求重定向到所需的后端目标。
例如，该应用程序包含一个开放重定向漏洞，其中以下 URL：/product/nextProduct?currentProductId=6&path=http://evil-user.net
返回重定向到：http://evil-user.net
您可以利用开放重定向漏洞绕过URL过滤，利用SSRF漏洞，如下：
1 | POST /product/stock HTTP/1.0 |
此 SSRF 漏洞之所以有效，是因为应用程序首先验证提供的stockAPI URL 是否位于允许的域上（事实确实如此）。然后，应用程序请求提供的 URL，这会触发开放重定向。它遵循重定向，并向攻击者选择的内部 URL 发出请求。
隐藏的SSRF 漏洞
如果您可以导致应用程序向提供的 URL 发出后端 HTTP 请求，但后端请求的响应未在应用程序的前端响应中返回，则会出现 隐藏的SSRF漏洞。
隐藏的SSRF更难利用，但有时会导致在服务器或其他后端组件上完全远程执行代码。
寻找 SSRF 漏洞的隐藏攻击点
许多服务器端请求伪造漏洞很容易被发现，因为应用程序的正常流量涉及包含完整URL的请求参数。 SSRF 的其他示例更难找到。
请求中的部分 URL
有时，应用程序仅将主机名或 URL 路径的一部分放入请求参数中。然后，提交的值会在服务器端合并到所请求的完整 URL 中。如果该值很容易被识别为主机名或 URL 路径，则潜在的攻击面可能是显而易见的。但是，作为完整 SSRF 的可利用性可能会受到限制，因为您无法控制所请求的整个 URL。
数据格式中的 URL
某些应用程序以某种规范传输数据，该规范允许包含数据解析器可能请求该格式的 URL。一个明显的例子是 XML 数据格式，它已广泛用于 Web 应用程序中，用于将结构化数据从客户端传输到服务器。当应用程序接受 XML 格式的数据并解析它时，它可能容易受到XXE 注入的攻击。它还可能容易通过 XXE 受到 SSRF 的攻击。当我们研究 XXE 注入漏洞时，我们将更详细地介绍这一点。
通过 Referer 标头进行 SSRF
一些应用程序使用服务器端分析软件来跟踪访问者。该软件通常会在请求中记录 Referer 标头，因此它可以跟踪传入链接。通常，分析软件会访问 Referer 标头中出现的任何第三方 URL。这样做通常是为了分析引用站点的内容，包括传入链接中使用的锚文本。因此，Referer 标头通常是 SSRF 漏洞的有用攻击面。
参考资料
- 本文作者： Qborfy
- 本文链接： https://www.qborfy.com/today_2024/20240814.html
- 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！
