SSRF基础原理(Server-side request forgery)

SSRF基础原理(Server-side request forgery)

什么是 服务器端请求伪造?

服务器端请求伪造（也称为 SSRF）是一种 Web 安全漏洞，允许攻击者诱导服务器端应用程序向攻击者选择的任意域发出 HTTP 请求。

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

pikachu 案例

curl

//payload:
//file:///etc/passwd  读取文件
//http://192.168.1.15:22 根据banner返回,错误提示,时间延迟扫描端口

if(isset($_GET['url']) && $_GET['url'] != null){

    //接收前端URL没问题,但是要做好过滤,如果不做过滤,就会导致SSRF
    $URL = $_GET['url']; 
    $CH = curl_init($URL);
    curl_setopt($CH, CURLOPT_HEADER, FALSE);
    curl_setopt($CH, CURLOPT_SSL_VERIFYPEER, FALSE);
    $RES = curl_exec($CH);
    curl_close($CH) ;
//ssrf的问是:前端传进来的url被后台使用curl_exec()进行了请求,然后将请求的结果又返回给了前端。
//除了http/https外,curl还支持一些其他的协议curl --version 可以查看其支持的协议,telnet
//curl支持很多协议，有FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE以及LDAP
    echo $RES;

我们可以把 url 中的内容改成内网的其他服务器上地址和端口，探测内网的其他信息，比如端口开放情况

也可以读取文件

file_get_content

//读取PHP文件的源码:php://filter/read=convert.base64-encode/resource=ssrf.php
//内网请求:http://x.x.x.x/xx.index
if(isset($_GET['file']) && $_GET['file'] !=null){
    $filename = $_GET['file'];
    $str = file_get_contents($filename);
    echo $str;

file_get_content 也可以对本地和远程的文件进行读取

读php代码内容显示为base64的形式

http://xiu.com/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php

改变路径

http://xiu.com/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=../../../l.php

PortSwigger 案例

针对本地服务器的基本 SSRF

该实验室具有库存检查功能，可从内部系统获取数据。

正常访问

浏览/admin并观察您无法直接访问管理页面。

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

针对另一个后端系统的基本 SSRF

使用库存检查功能192.168.0.X在端口 8080 上扫描管理界面的内部范围,其他同上

正常访问
burp爆破出正确端口

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

• 使用 的替代 IP 表示127.0.0.1，例如2130706433、017700000001或127.1。
• 注册您自己的解析为127.0.0.1. 您可以spoofed.burpcollaborator.net用于此目的。
• 使用 URL 编码或大小写变体混淆被阻止的字符串。

开发人员部署了两个需要绕过的弱反 SSRF 防御。其他同上

127.1 能够绕过

更改为http://127.1/admin观察 URL 再次被阻止。

通过双 URL 编码将“a”混淆为 %2561 以访问管理界面

通过开放重定向漏洞绕过过滤器的 SSRF

更改库存检查 URL 以访问管理界面http://192.168.0.12:8080/admin并删除用户carlos。库存检查器已被限制为只能访问本地应用程序，因此您需要首先找到影响应用程序的开放重定向。

正常请求

尝试篡改stockApi参数并观察无法让服务器直接向不同的主机发出请求。

点击“下一个产品”，观察path参数被放入重定向响应的Location头中，导致打开重定向。
创建一个利用开放重定向漏洞的 URL，并重定向到管理界面，并将其stockApi输入参数中

带有基于白名单的输入过滤器的 SSRF

某些应用程序只允许匹配、以或包含允许值的白名单的输入。在这种情况下，您有时可以通过利用 URL 解析中的不一致来绕过过滤器。URL 规范包含许多在实现 URL 的即席解析和验证时容易被忽视的特性：

• 可以使用@字符 在主机名之前的 URL 中嵌入凭据。例如：

https://expected-host@evil-host

• 可以使用该#字符来指示 URL 片段。例如：

https://evil-host#expected-host

• 可以利用 DNS 命名层次结构将所需的输入放入您控制的完全限定的 DNS 名称中。例如：

https://expected-host.evil-host

• 可以对字符进行 URL 编码以混淆 URL 解析代码。如果实现过滤器的代码处理 URL 编码字符的方式不同于执行后端 HTTP 请求的代码，这将特别有用。

开发人员已经部署了您需要绕过的反 SSRF 防御。

stockApi将参数中 的 URL 更改为http://127.0.0.1/并观察应用程序正在解析 URL、提取主机名并根据白名单对其进行验证

添加@ ,这表明 URL 解析器支持嵌入式凭据。

附加 # 观察该 URL 现在被拒绝。

双 URL 编码#到%2523

找到管理面板

stockApi=http://localhost:80%[email protected]/admin

漏洞寻找

请求中的部分 URL

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

数据格式中的 URL

一些应用程序以其规范允许包含可能由数据解析器请求的格式的 URL 的格式传输数据。一个明显的例子是 XML 数据格式，它已广泛用于 Web 应用程序中，用于将结构化数据从客户端传输到服务器。当应用程序接受 XML 格式的数据并对其进行解析时，它可能容易受到XXE 注入的攻击，进而容易受到 XXE 的 SSRF 攻击

通过Referer头的SSRF

一些应用程序使用跟踪访问者的服务器端分析软件。该软件经常在请求中记录 Referer 标头，因为这对于跟踪传入链接特别有用。通常，分析软件实际上会访问出现在 Referer 标头中的任何第三方 URL。这通常用于分析引用站点的内容，包括传入链接中使用的锚文本。因此，Referer 标头通常代表 SSRF 漏洞的有效攻击面。