API 中的服务端请求伪造 （SSRF）

在 API 中利用服务器端请求伪造 （SSRF）

并非所有 API 漏洞都是平等的。服务器端请求伪造 （SSRF） 攻击是最危险的攻击之一，因为它们会影响 Web 应用程序及其 API。事实上，它非常危险，最近已被添加到
OWASP API Security TOP 10 中，您可以在此处阅读相关信息。

随着威胁形势的不断发展，Web 应用程序安全也必须不断发展。如果 REST API 中的易受攻击代码无法正确验证用户输入，则最终可能允许访问数据或允许在托管 API 的 Web 服务器上远程执行代码。

在本文中，我们将探讨 SSRF 的来龙去脉，如何利用它，并提供测试 API 以帮助发现此类漏洞的提示。

什么是服务器端请求伪造 （SSRF）？

服务器端请求伪造（Server Side Request Forgery，也称为 SSRF）是一种安全漏洞，它允许恶意威胁行为者诱使 Web 应用程序或 API 的服务器端执行未经授权的操作。

这种复杂的攻击形式涉及诱骗服务器通过攻击者可能控制的网络连接向另一台计算机发送请求，这可能导致敏感数据泄露，允许攻击者访问文件和资源，允许远程代码执行，甚至导致服务器崩溃。

与应用程序安全领域最常见的情况一样，当我们盲目相信用户输入时，像 SSRF 这样的软件漏洞就会被滥用。

SSRF 攻击可能非常难以检测，因此，它们仍然是当今企业的重大威胁。组织需要采取主动措施来保护其 Web 应用程序免受 SSRF 攻击的潜在破坏性影响，包括实施适当的安全控制和定期进行漏洞测试。

常规 SSRF 与盲 SSRF

典型的 SSRF 攻击将允许攻击者以服务器响应的形式从 Web 应用程序或 API 获取反馈，这通常包括请求的任何未经授权操作的结果。

然而，盲目的 SSRF 攻击要复杂得多。盲目 SSRF 漏洞的结果可能会在没有服务器任何响应的情况下发生。这意味着攻击者可能对所发生的事情知之甚少或一无所知。

有时，攻击者可以触发部分盲 SSRF 攻击。在这些情况下，虽然他们通常不会获得有用的结果响应，但他们可能会利用 HTTP 响应中的内容长度、响应时间或 HTTP 状态代码来跟踪其利用的成功。

如何识别 API 中的 SSRF 漏洞

发现服务器端请求伪造漏洞通常相对容易，尤其是当 API 的流量涉及请求参数或打包有完整 URL 的有效负载时。然而，一些 SSRF 案例可能被证明更加难以捉摸和难以确定。

要成功绕过服务器端代码中的输入验证，您需要巧妙地处理如何篡改可能创建外部请求的潜在片段。通过战略性地污染这些片段，人们有可能获得对隐藏在原始响应正文中的数据的访问权限。这是一场策略和技巧的游戏，所以系好安全带，准备好玩吧。

让我们探索一下您可能会在哪里找到 SSRF 漏洞。

常见的易受攻击的参数名称

早在 Jason Haddix 在 BugCrowd 工作的日子里，他为 Burp Suite 和 ZAP 构建了一套名为 HUNT suite 的扩展，旨在查找 Web 应用程序中的易受攻击的参数。

如果你查看其 SSRF 扫描程序扩展的配置数据，你会发现已经对常见参数名称进行了大量安全研究，包括：

Common vulnerable parameter namesdest
redirect
uri
path
continue
url
window
next
data
reference
site
html
val
validate
domain
callback
return
page
feed
host
port
to
out
view
dir
show
navigation
open

在侦察过程中，请确保收集请求中的所有参数名称，并在搜索敏感信息时查找这些参数。它们是可能容易受到 SSRF 攻击的参数的良好指标。发送污染这些参数的自定义数据，看看会发生什么。

你永远不知道会发生什么。

Webhook

API 对于现代软件开发至关重要，它支持不同应用程序和系统之间的无缝通信。开发人员执行此操作的一种方法是使用传出 Webhook。

API 可能会结合使用用户控制的数据和第三方服务 URL 片段来构建它将调用的 URL。通过操纵这些 webhook，黑客可以使用 SSRF 攻击来获得对服务器的未经授权的访问，并可能窃取敏感数据或造成其他损害。

有时，Web 应用程序可能允许用户输入 URL，以便在发生特定事件时执行自定义 Webhook。像 Zapier 这样的公司的存在是为了帮助基于这种事情构建工作流程自动化。作为其中的一部分，有时它们包括验证/测试输入的给定 webhook URL 的功能。

这通常可能被滥用，允许攻击者让服务器向专用网络上的内部资源发出请求，验证主机或服务的存在（又名跨站点端口攻击），甚至在意想不到时返回数据。

文件导入

许多 Web 应用程序依赖于导入文件的需求。这可能是从社交媒体资料中提取的图片、存储在云提供商处的在线电子表格，或者可能是来自外部 Web 源的文本文件。

你明白了。

不管是什么，如果 API 依赖 URL 来导入文件，它可能容易受到服务器端请求伪造的攻击。

对此进行测试的一种简单方法是输入 的 URL，即典型的云元数据服务。如果预期文件以任何方式回显或存储以供以后检索，您将能够看到元数据服务请求的结果。http://169.254.169.254

另一种方法是使用 localhost （127.0.0.1），看看你是否可以通过 URL 路径遍历访问与外部 Web 服务器匹配的资源。如果是这样，您可以将其用作攻击媒介来提取通常不由 Web 服务器提供的内部资源。

PDF 生成

如果 API 根据用户控制的任何输入动态生成 PDF，则它可能容易受到服务器端请求伪造的攻击。

攻击者可以污染数据，以便在呈现 PDF 时，它可能会以服务器端 XSS 的形式加载任意数据。如果该 XSS 包含 javascript 或嵌入了 iframe，则它可能能够向内部服务器发出请求并将结果存储在 PDF 中。

我最喜欢的例子是 Stok 录制的一段视频，当时 Nahamsec 和朋友们在纽约拼车寻找美味的热狗时入侵了 Lyft。

利用 SSRF 漏洞的方法

虽然我之前快速给出了一些关于测试某些形式的 SSRF 的示例，但您可以用它做更多的事情，具体取决于您发现的内容。

本地/远程端口扫描

本地和远程端口扫描是利用 SSRF 漏洞的两种常用方法。

有时，远程端口扫描称为跨站点端口攻击。它希望通过对内部主机上的目标端口扫描来滥用私有 IP 地址来访问本地网络和其中的资源。

远程扫描端口对于希望利用 SSRF 漏洞的攻击者特别有效。他们可以通过易受攻击的 API 的服务器路由请求数据包，使请求看起来好像来自服务器本身，从而绕过访问内部网络时没有的典型安全措施。

举个简单的例子，如果你想知道 API 服务器是否在内部网络上启用了 SSH。如果您在 url 参数中发现易受 SSRF 攻击的终端节点，您可能会用“？url=http：//127.0.0.1:22”对其进行污染，并查看它是否返回 SSH 横幅。

本地文件读取

在查看 SSRF 漏洞时，最好跳出框框思考究竟是什么导致服务器发出请求。如果它使用无头服务器端代码或 curl 或 get 等工具获取 URL，则可以利用替代协议来访问资源。

例如，您可以将 http:// 协议替换为 file://，从而允许您访问服务器文件系统上的文件。常见示例包括基于 nix 的系统上的 “？url=file:///etc/passwd” 或基于 Windows 的系统上的 “？url=file://C:/boot.ini”。

与内部服务交互

SSRF 漏洞可能向攻击者暴露的一个令人兴奋的机会是，他们能够访问内部网络上的服务，而这些服务在应用程序服务器的网络边界上不可见。

想一想。API 服务器需要联系多少个后端系统才能完成事务？也许它需要从 redis 或 memcache 等缓存系统获取短期数据。然后，它需要将长期数据写入 MySQL 或 PostgreSQL 等数据存储。

多亏了 SSRF，所有这些内部资源都开始发挥作用。

还记得之前我提到您可以将 URL 架构从 http:// 更改为 file:// 以访问内部文件吗？嗯，在某些情况下，你可以切换到更复杂的协议，比如 gopher:// 来更进一步，将一大堆表达式/指令链接起来，以便在单个请求中与其他系统进行交互。这是一篇有趣的文章，展示了一些可以做到这一点的安全研究。

访问云元数据

大多数提供云计算服务的供应商都包括对云元数据服务的访问。此服务通常只能由后端组件访问内部 IP：

• 对于大多数云服务，如 AWS、Azure、Digital Ocean、RackSpace、HP 等，这通常是169.254.169.254
• 对于 Oracle 来说，这是192.0.0.192
• 对于阿里巴巴来说，这是100.100.100.200

如果服务器通过 HTTP 连接到它，它可以提取敏感信息，这些信息很容易通过服务器端请求伪造 （SSRF） 被滥用。这包括从配置数据到访问令牌的所有内容。

BuffaloWill 在 GitHub gist 中发布了一个很棒的云元数据词典，您可以在 SSRF 测试期间使用。在 Burp Suite 中创建的快速 Intruder 负载可能会尝试通过将目标 URL 替换为该字典中的输入来滥用潜在的 SSRF 漏洞。

绕过 SSRF 保护的方法

随着后端 SSRF 攻击继续滥用弱 Web 应用程序和 API，开发人员的目光超越了验证用户输入的安全控制。新的 SSRF 保护旨在防止攻击者修改资源、访问组件的文件系统或查询支持 HTTP 的数据库。

当然，如果您知道如何操作，通常有一些方法可以绕过这些保护。

让我们介绍几个示例。

使用外来 URL 架构

如果开发人员不禁用未使用的 URL 架构，那么这是在 SSRF 测试期间滥用的完美攻击媒介。我之前提到过 gopher:// 和 file:// 等遗留 URL 架构，它们可能会以这种方式被滥用。

但是，OWASP SSRF 圣经发布了一份也可以使用的其他潜在危险的列表。我最喜欢的一些包括：

Potentially dangerous URL schemasdict://
file://
ftp://
gopher://
ldap://
smtp://
telnet://
tftp://

我只尝试了这些 URL 架构。但是 OWASP 文档包括其他几个像 expect:// 一样的文档，它们过去曾被滥用到整个 PHP Web 应用程序。因此，值得进一步研究以查找 API 目标上可用的 URL 架构支持组合。

使用主机名而不是 IP

有时，开发人员会尝试聪明地阻止 HTTP 请求，这些请求可能包括云元数据服务和 localhost （127.0.0.1） 等的已知 IP。

但是，这些有时可以映射到未过滤掉的内部主机名。

一个简单的例子是 metadata.google.internal。

另一种方法是使用外部 DNS 服务（如 nip.io），它允许您将几乎任何内容映射到通配符 DNS 条目。使用十六进制表示法，您可以映射到 a9fea9fe.nip.io。或者您可以映射到 7f000001.nip.io。169.254.169.254 127.0.0.1

非标准 IP 表示法

既然我们正在讨论以十六进制等格式操作 IP 地址，我们不要忘记我们可以滥用其他非标准 IP 表示法。

以下是全部解析为 ：169.254.169.254

• 十六进制 –0xa9fea9fe
• 整数 –2852039166
• IPv6 协议 –::ffff:a9fe:a9fe
• 八进制 –025177524776

重定向

最后但同样重要的是滥用开放重定向来绕过 SSRF 用户输入过滤器保护。如果我们可以在一个域上托管一个简单的脚本，我们可以通过 HTTP 重定向来控制和访问，我们可能能够使我们希望访问的内部服务器被过滤掉。302 redirect

结论

服务器端请求伪造 （SSRF） 攻击将继续存在。它们现在是OWASP API Security TOP 10最新修订版的一部分，这是有充分理由的。

对 API 的成功 SSRF 攻击可能只是一个 HTTP 请求。您准备好进行测试了吗

通过了解 SSRF 的工作原理以及在 API 中利用它的不同方式，开发人员可以确保在 API 中添加新应用程序功能时，Web 应用程序的安全性始终受到关注，并且 API 黑客可以增加他们的测试方法，以包含更强大的 SSRF 攻击。