SSRF Server-Side Request Forgery(服务器端请求伪造)

什么是SSRF?

犹如其名,SSRF(Server-Side Request Forgery)服务端请求伪造，攻击者可以控制服务器返回的页面，借用服务器的权限访问无权限的页面。

这是一个允许恶意用户导致网络服务器向攻击者选择的资源发出附加或编辑的HTTP请求的漏洞。

SSRF 的类型

有两种类型的 SSRF 漏洞；第一个是常规的 SSRF，其中数据返回到攻击者的屏幕。

第二种是盲目 SSRF 漏洞，发生 SSRF，但没有信息返回到攻击者的屏幕

成功的 SSRF 攻击可能导致以下任何情况：

进入未经授权的区域
访问客户/组织数据。
能够扩展到内部网络
显示身份验证令牌/凭证

示例:

我们将带您了解一些SSRF攻击示例，并解释它们的工作原理

说明书

以下示例显示了攻击者如何完全控制Web服务器请求的页面。

Expected Request是website.thm服务器期望接收的内容，红色部分是网站获取信息的URL。

攻击者可以将红色区域修改为自己选择的URL

下面的示例显示了攻击者如何仍然可以通过使用目录遍历来访问/api/user页面，而只需控制路径。当website.thm收到../这是一条向上移动目录的消息，该目录删除了请求的/stock部分，并将最终请求转换为/api/user

在此示例中，攻击者可以控制向其发出请求的服务器子域。请注意以&x=结尾的有效负载用于阻止将剩余路径附加到攻击者URL的末尾，并将其转换为查询字符串上的参数（？x=）

回到原始请求，攻击者可以强制Web服务器请求攻击者选择的服务器。通过这样做，我们可以捕获发送到攻击者指定域的请求标头。这些标头可能包含website.thm发送的身份验证凭据或API密钥（通常会向API.website.thm）

使用您所学的内容，尝试更改下面浏览器中的地址，以强制Web服务器从https://server.website.thm/flag?id=9.

为了更方便，模拟浏览器底部的服务器请求栏将显示website.thm请求的URL

使用&截断，是服务器认为server参数的值已经传输完毕

如何发现SSRF

可以通过许多不同的方式在 Web 应用程序中发现潜在的 SSRF 漏洞。以下是四个常见位置的示例：

在地址栏的参数中使用完整 URL 时：

表单中的隐藏字段：

部分 URL，例如主机名：

或者可能只是 URL 的路径：

其中一些示例比其他示例更容易被利用，而这正是需要大量试验和错误才能找到有效负载的地方

如果使用没有输出的盲目 SSRF，您将需要使用外部HTTP日志记录工具来监视请求，例如 http://requestbin.com、您自己的 HTTP 服务器或 Burp Suite 的 Collaborator 客户端

常见的防御

了解 SSRF 漏洞风险的更多精通安全的开发人员可能会在其应用程序中实施检查，以确保请求的资源符合特定规则。通常有两种方法，拒绝列表或允许列表，简单来说就是黑名单和白名单

拒绝列表

拒绝列表是除了列表中指定的资源或与特定模式匹配的资源之外的所有请求都被接受的地方

Web 应用程序可以使用拒绝列表来保护敏感端点、IP 地址或域不被公众访问，同时仍然允许访问其他位置。限制访问的特定端点是 localhost，它可能包含服务器性能数据或其他敏感信息，因此 localhost 和 127.0.0.1 等域名将出现在拒绝列表中

绕过方法

攻击者可以通过使用替代本地主机引用（例如 0、0.0.0.0、0000、127.1、127...*、2130706433、017700000001 或具有解析为 IP 地址 127.0.0.1 的 DNS 记录的子域）来绕过拒绝列表例如 127.0.0.1.nip.io

此外，在云环境中，阻止对 IP 地址 169.254.169.254 的访问将是有益的，该地址包含已部署云服务器的元数据，包括可能的敏感信息。攻击者可以通过在自己的域上注册一个子域来绕过此问题，该子域的DNS记录指向 IP 地址 169.254.169.254

允许列表

允许列表是拒绝所有请求的地方，除非它们出现在列表中或匹配特定模式,例如参数中使用的 URL 必须以 https://website.thm 开头的规则

绕过方法

攻击者可以通过在攻击者的域名上创建子域来快速规避此规则，例如 https://website.thm.attackers-domain.thm。应用程序逻辑现在将允许此输入并让攻击者控制内部HTTP请求

打开重定向

如果上述旁路不起作用，攻击者还有一个妙招，即打开重定向。开放重定向是服务器上的一个端点，网站访问者会自动重定向到另一个网站地址。以链接为例https://website.thm/link?url=https://tryhackme.com.创建此端点是为了记录访问者出于广告/营销目的点击此链接的次数。但想象一下，存在一个潜在的SSRF漏洞，该漏洞具有严格的规则，仅允许以开头的URLhttps://website.thm/.攻击者可以利用上述功能将内部HTTP请求重定向到攻击者选择的域

实际例子

在针对Acme IT 支持网站的内容发现练习中，我们遇到了两个新端点。第一个是 /private

它给我们一条错误消息，说明无法从我们的 IP 地址查看内容

第二个是位于/customers/new-account-page的新版客户帐户页面

其中包含一项新功能，允许客户为他们的帐户选择头像，进入该页面需要先将注册一个用户然后登录

右键检查查看新的头像选择功能,通过查看头像表单的页面源代码，您会看到头像表单字段值包含图像的路径。根据下面的屏幕截图，背景图像样式可以在上面的 DIV 元素中确认这一点：

尝试正确的更改一次头像,在我们提交修改头像的时候，会将该路径提交更改为我们的头像，

更改后发现图片显示到了页面，并且显示了图片的base64编码内容

所以我们将图片的提交地址改为/private的地址，该页面就会讲/private的值使用base64编码返回

尝试:

修改后提交查看

提示我们不能已/private开头，我们可以使用Junglezt/../private尝试，Junglezt/的意思是选择并进入Junglezt/目录不管是否存在，然后再使用../跳出Junglezt目录，等于原地踏步，但是可以绕过识别不能已/privite的限制

可以看到头像设置完成，这是我们只需要查看页面源代码，将base64编码信息进行解密即可

VEhNe1lPVV9XT1JLRURfT1VUX1RIRV9TU1JGfQ==

解码

echo VEhNe1lPVV9XT1JLRURfT1VUX1RIRV9TU1JGfQ== | base64 -d

THM{YOU_WORKED_OUT_THE_SSRF}