【BP靶场portswigger-服务端9】服务端请求伪造SSRF漏洞-7个实验(全)(上)

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 【BP靶场portswigger-服务端9】服务端请求伪造SSRF漏洞-7个实验(全)(上)

一、服务器端请求伪造(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,发现您无法直接访问管理页面


97ed8c36e46d4e0abd9edde8c086a358.png


part2:


访问一个产品,点击"检查库存",拦截请求,并将其发送到repeater


123ec1e15f3c4fd69b2010055e346e9e.png


将stockApi参数中的URL更改为http://localhost/admin(将显示管理界面)

0ae5c18b8b9d42be98c1367b267363a2.png

读取HTML以标识要删除目标用户的URL,该URL为:


http://localhost/admin/delete?username=carlos

d91cdb9b9f504f999282a45b825e8599.png

在stockApi参数中提交此URL,以传递SSRF攻击。


5ff303a1f6de4309a805581ace9c596e.png


刷新页面


8051496b7c154b0485a54c72d4273c5d.png


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中拦截请求


fef80bde3f3a4a5783b5131c0e637691.png


part2:


进行攻击


并将其发送到Burp入侵者

先"Clear §",将 stockApi 参数更改为http://192.168.0.1:8080/admin


然后突出显示 IP 地址的最后八位数(数字1) ,点击Add§


ce3cd58b9dd942ef931938715142746d.png


Payloads设置,将有效负载类型更改为Numbers,并在"From"、"To"和"Step"框中分别输入1、255和1


并单击"开始攻击"


c353d49fb5e042bd9d57e73074835a26.png


按状态代码升序对其进行排序,看到一个状态为200的条目,其中显示了一个管理界面


f9d399603c854449a014db9c263666b0.png



右键此请求,将其发送到Burp Repeater,并将stockApi中的路径更改为:


http://192.168.0.135:8080/admin/delete?username=carlos

0dc41c60a5994a41ba5f73cbe5fc48eb.pngb10d746a0dff454fbd6f2344f7acc1b9.png

三、绕过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


ff780a1e41d44231bb5675cd6c7028b8.png



改变stockApi参数为


http://127.0.0.1/


错误提示,看出并观察到请求被阻止

7bcc491694644d9a8be66f8b577edcaf.png


part2:


绕过过滤器

通过将URL更改为


http://127.1/

b637bd39aa63464091d4c149b872628a.png

将URL更改为


http://127.1/admin


并观察到该URL再次被阻止

4c98729c1aba4f998faee394ba344d36.png


将"a"进行双URL编码为%2561


http://127.1/%2561dmin

8e223ca1853b417ba03ef6bc567ebc7f.png


/admin/delete?username=carlos
part3:


完成实验


以访问管理界面并删除目标用户


http://127.1/%2561dmin/delete?username=carlos

9a371a82b6034ab0965c114cd10d0dc5.png0f531e3e282940738033bca8ec581bd2.png

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

5515e16419084007b73cb21847254798.png


将stockApi参数中的URL更改为


http://127.0.0.1/


然后观察应用程序是否正在解析URL、提取主机名并根据白名单对其进行验证。

77d737fa6bcd45abac9c707c72d73315.png


将URL更改为


http://username@stock.weliketoshop.net/


并观察其是否被接受,结果表明URL解析器支持嵌入式凭据

1c90cfb6f382424e85495591e24582e7.png


在用户名后附加一个#,观察URL被拒绝


6574068a7aea44e8b34bb4705d46f4e0.png


双URL将#编码为%2523,并观察非常可疑的“Internal Server Error”响应,该响应指示服务器可能已尝试连接到“username”


7e3ed317c14448b6b23c0f5a5bbef41d.png


part2:


完成实验


要访问管理界面并删除目标用户,将URL更改为:


http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

d76d84ccebd949cfb426161e70834da3.png


3665dbb6ade74a3d8978bc1751ea39b9.png



目录
相关文章
|
存储 Web App开发 JavaScript
【BP靶场portswigger-客户端11】跨站点脚本XSS-20个实验(上)
【BP靶场portswigger-客户端11】跨站点脚本XSS-20个实验(上)
1225 0
【BP靶场portswigger-客户端11】跨站点脚本XSS-20个实验(上)
pikachu靶场通过秘籍之服务端请求伪造攻击
pikachu靶场通过秘籍之服务端请求伪造攻击
90 0
|
XML 安全 网络协议
【BP靶场portswigger-服务端9】服务端请求伪造SSRF漏洞-7个实验(全)(下)
【BP靶场portswigger-服务端9】服务端请求伪造SSRF漏洞-7个实验(全)(下)
407 0
【BP靶场portswigger-服务端9】服务端请求伪造SSRF漏洞-7个实验(全)(下)
|
存储 Web App开发 安全
【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验(全)(上)
【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验(全)(上)
816 0
【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验(全)(上)
|
存储 Web App开发 安全
【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验(全)(下)
【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验(全)(下)
679 0
【BP靶场portswigger-客户端12】跨站点请求伪造CSRF-12个实验(全)(下)
|
安全 Java Shell
BP靶场portswigger-服务端8】文件上传漏洞-7个实验(全)(上)
BP靶场portswigger-服务端8】文件上传漏洞-7个实验(全)(上)
369 0
BP靶场portswigger-服务端8】文件上传漏洞-7个实验(全)(上)
|
JSON 安全 Oracle
【bp靶场portswigger-服务端2】身份认证漏洞-16个实验(全)(上)
【bp靶场portswigger-服务端2】身份认证漏洞-16个实验(全)(上)
571 0
【bp靶场portswigger-服务端2】身份认证漏洞-16个实验(全)(上)
|
安全 前端开发 中间件
【bp靶场portswigger-服务端2】身份认证漏洞-16个实验(全)(下)
【bp靶场portswigger-服务端2】身份认证漏洞-16个实验(全)(下)
488 0
【bp靶场portswigger-服务端2】身份认证漏洞-16个实验(全)(下)
|
SQL Oracle 安全
【BP靶场portswigger-服务端1】SQL注入-17个实验(全)(上)
【BP靶场portswigger-服务端1】SQL注入-17个实验(全)
338 0
【BP靶场portswigger-服务端1】SQL注入-17个实验(全)(上)
|
SQL 关系型数据库 MySQL
【BP靶场portswigger-服务端1】SQL注入-17个实验(全)(下)
【BP靶场portswigger-服务端1】SQL注入-17个实验(全)(下)
388 0
【BP靶场portswigger-服务端1】SQL注入-17个实验(全)(下)