服务器端请求伪造 (SSRF)

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

什么是 SSRF？

服务器端请求伪造（也称为 SSRF）是一种 Web 安全漏洞，允许攻击者诱导服务器端应用程序向非预期位置发出请求。

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

SSRF 攻击的影响是什么？

服务器端请求伪造（也称为 SSRF）是指攻击者从易受攻击的 Web 应用程序的后端服务器发送精心设计的请求的攻击。

攻击者通常使用 SSRF 来攻击位于防火墙后面且无法从外部网络访问的内部网络。

当攻击者完全或部分控制 Web 应用程序发送的请求时，就会出现 SSRF 漏洞。如果存在漏洞的 Web 应用程序处理用户提供的 URL，则该应用程序很容易受到 SSRF 攻击。

跨站端口攻击（XSPA）也是 SSRF 的一部分。在 XSPA 中，攻击者可以借助处理用户 URL 的易受攻击的 Web 应用程序来扫描目标 Web 服务器的开放端口。

图片[2]-ssrf-exploit：服务器端请求伪造 (SSRF) 的利用-IT熊技术站

常见的SSRF攻击

SSRF 攻击通常利用信任关系来升级易受攻击的应用程序的攻击并执行未经授权的操作。这些信任关系可能与服务器本身相关，或者与同一组织内的其他后端系统相关。

服务器端请求伪造攻击的影响

如果用户提供的 URL 已被处理且后端响应未经过清理，则攻击可能会导致多种影响，例如：

端口扫描：用户可以通过处理用户 URL 的易受攻击的 Web 应用程序扫描特定网站的端口。
指纹识别内网。
攻击内部或外部 Web 应用程序。
使用 file:/// 协议处理程序读取本地 Web 服务器文件。
在某些情况下，成功的 SSRF 攻击甚至可能导致远程代码执行 (RCE)。

针对服务器本身的 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。但管理功能通常只有经过适当身份验证的用户才能访问。因此，直接访问 URL 的攻击者不会看到任何感兴趣的内容。但是，当对 /admin URL 的请求来自本地计算机本身时，正常的访问控制将被绕过。应用程序授予对管理功能的完全访问权限，因为请求似乎源自受信任的位置。

为什么应用程序会以这种方式运行，并隐式信任来自本地计算机的请求？出现这种情况的原因有多种：

访问控制检查可以在位于应用程序服务器前面的不同组件中实现。当返回到服务器本身的连接时，检查将被绕过。
出于灾难恢复的目的，应用程序可能允许来自本地计算机的任何用户无需登录即可进行管理访问。这为管理员提供了一种在丢失凭据时恢复系统的方法。这里的假设是只有完全受信任的用户才会直接来自服务器本身。
管理界面可能正在侦听与主应用程序不同的端口号，因此用户可能无法直接访问。这种信任关系（来自本地计算机的请求的处理方式与普通请求不同）通常是导致 SSRF 成为严重漏洞的原因。

针对其他后端系统的 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

规避常见的 SSRF 防御

包含 SSRF 行为以及旨在防止恶意利用的防御措施的应用程序很常见。通常，这些防御措施是可以被规避的。

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

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

使用替代 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) 的利用

内置

虽然我是这个项目的主要开发人员，但如果没有这些开源项目的帮助，这个项目甚至无法启动，特别感谢：

[Python]

入门

这是一个示例，说明如何在本地设置项目。要启动并运行本地副本，请按照以下简单的示例步骤操作。

先决条件

该计划没有先决条件

安装与使用

克隆存储库

git clone https://github.com/errorfiathck/ssrf-exploit.git

cd ssrf-exploit

运行脚本作为示例：

python3 ssrf-exploition.py --help

玩得开心！

项目地址

ssrf-exploit：【GitHub】

文章版权声明 1、本网站名称：IT熊技术站
2、本站永久网址：https://www.cutrui.cn
3、本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
6、根据《计算机软件保护条例》第十七条，本站所有软件请仅用于学习研究用途

THE END