SSRF全称:Server-Side Request Forgery,即 服务器端请求伪造。是一个由攻击者构造请求,在目标服务端执行的一个安全漏洞。攻击者可以利用该漏洞使服务器端向攻击者构造的任意域发出请求,目标通常是从外网无法访问的内部系统。简单来说就是利用服务器漏洞以服务器的身份发送一条构造好的请求给服务器所在内网进行攻击。
当攻击者想要访问服务器B上的服务,但是由于存在防火墙或者服务器B是属于内网主机等原因导致攻击者无法直接访问。如果服务器A存在SSRF漏洞,这时攻击者可以借助服务器A来发起SSRF攻击,通过服务器A向主机B发起请求,达到攻击内网的目的。
示例:
漏洞场景:某网站有一个在线加载功能可以把指定的远程文章加载到本地,链接如下:
http://www.xxx.com/article.php?url=https://blog.csdn.net/qq_43531669/article/details/112498646
假如系统没有对url参数进行任何的检查,就可以构造其他的请求,例如:
http://www.xxx.com/article.php?url=http://127.0.0.1:22
http://www.xxx.com/article.php?url=file:///etc/passwd
http://www.xxx.com/article.php?url=dict://127.0.0.1:22/data:data2 (dict可以向服务端口请求data data2)
http://www.xxx.com/article.php?url=gopher://127.0.0.1:2233/_test (向2233端口发送数据test,同样可以发送POST请求)
...
很多网站提供了从其他的服务器上获取数据的功能。通过指定的URL,网站可以从其他地方获取图片、下载文件、读取文件内容等。SSRF的实质就是利用存在缺陷的Web站点作为代理攻击远程和本地的服务器。
SSRF漏洞形成的原因大都是由于服务端提供了从其他服务器获取数据的功能但没有对目标地址做过滤与限制。攻击者可以利用改漏洞获取内部系统的一些信息(因为它是由服务端发起的,所以它能够请求到与它相连而与外网隔离的内网系统)。
对外网、服务器所在内网、本地进行端口扫描
向内部任意主机的任意端口发送payload来攻击内网服务
DOS攻击(请求大文件,始终保持连接Keep-Alive Always)
攻击内网的web应用,如直接SQL注入、XSS攻击等
利用file、gopher、dict协议读取本地文件、执行命令等
可以无视网站CDN
内网服务防御相对外网服务来说一般会较弱,甚至部分内网服务为了运维方便并没有对内网的访问设置权限验证,所以存在SSRF时,通常会造成较大的危害。
因为SSRF漏洞是构造服务器发送请求的安全漏洞,所以我们可以通过抓包分析发送的请求是否是由服务器端发送的来判断是否存在SSRF漏洞。
在页面源码中查找访问的资源地址,如果该资源地址类型为http://www.xxx.com/a.php?image=地址
就可能存在SSRF漏洞。
(1) 分享功能:通过URL地址分享文章等,例如如下地址:
http://share.xxx.com/index.php?url=http://www.xxx.com
通过url参数的获取来实现点击链接的时候跳到指定的分享文章。如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞。
(2)图片加载/下载:通过URL地址加载或下载图片:
http://image.xxx.com/image.php?image=http://www.xxx.com
图片加载存在于很多的编辑器中,编辑器上传图片处加载设定好的远程服务器上的图片地址,如果没对加载的参数做限制可能造成SSRF。
(3)图片/文章收藏功能:
http://title.xxx.com/title?title=http://title.xxx.com/xxx
例如 title参数是文章的标题地址,代表了一个文章的地址链接,如果收藏功能采用了此种形式保存文章,则在没有限制参数的形式下可能存在SSRF。
(4)转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览。
(5)在线翻译:给网址翻译对应网页的内容。
(6)邮件系统:比如接收邮件服务器地址。
(7)利用参数中的关键字查找:
关键字:
share、wap、url、link、src、source、target、u、3g、display、sourceURl、imageURL、domain...
总的来说,需要从远程服务器请求资源的网站都有可能存在SSRF漏洞。
部分存在漏洞,或者可能产生SSRF的功能中做了白名单或者黑名单的处理,来达到阻止对内网服务和资源的攻击和访问。因此想要达到SSRF的攻击,需要对请求的参数地址做相关的绕过处理,常见的绕过方式如下:
(1)利用@,当网站限制只能访问 http://www.xxx.com
类型的域名时,可以采用http基本身份认证的方式绕过,如:http://[email protected]
在对@解析域名中,不同的处理函数存在处理差异,例如:
http://[email protected]@www.ccc.com
在PHP的parse_url中会识别 www.ccc.com,而libcurl则识别为 www.bbb.com。
(1)采用短网址绕过
(2)利用特殊域名,xip.io可以指向任意域名(原理是DNS解析),即 127.0.0.1.xip.io,可以解析为127.0.0.1
(3)采用进制转换,127.0.0.1 八进制:0177.0.0.1
;十六进制:0x7f.0.0.1
;十进制:2130706433
(4)利用[::]
,http://[::]:80/
会解析为 http://127.0.0.1
(5)添加端口号,http://127.0.0.1:8080
(6)利用句号,127。0。0。1
会解析为 127.0.0.1
(7)采用302跳转
(1)采用302跳转
(2)采用短地址
根据后台使用的函数的不同,相应的影响和利用方法也不一样,PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
file_get_contents()
这个函数的作用是将整个文件读入一个字符串中,并且此函数是用于把文件的内容读入到一个字符串中的首选方法。
比如:下面的代码执行结果是输出test.txt文件里面的字符串。
echo file_get_contents(“test.txt”);
?>
fsockopen()
使用fsockopen函数实现获取用户制定url的数据(文件或者html)。
curl_exec()
该函数可以执行给定的curl会话。
这里使用pikachu靶场的ssrf模块进行演示。
2.1、SSRF(curl):
首先来看使用curl_exec()
函数的ssrf靶场,点击页面链接会返回一首诗,观察发现它传递了一个url请求给后台
查看后端代码,可以看到它是用get获取了前端的url请求,curl_exec函数执行请求,最终又将请求结果返回到前端。
curl_init //初始cURL会话
curl_exec //执行cURL会话
将上传的url修改为http://www.badiu.com,可以看到页面显示出了百度的数据
我们可以把url中的内容改成内网的其他服务器上地址和端口,探测内网信息,比如端口开放情况,例如,下图探测出内网主机 192.168.50.130 开放了22端口:
可以配合脚本或者Burp进行更高效的端口探测,例:
可以看到,检测到了内网主机的80端口是开放的
我们也可以通过SSRF漏洞读取内网服务器的文件,例如将url修改为
http://127.0.0.1/pikachu/vul/ssrf/ssrf_curl.php?url=file:///c:/windows/system.ini
同样点击页面标签,发现是使用file协议读取文件
查看后端代码
与上面大致相同,不同之处是它这里使用file_get_contents
函数进行文件的读取执行,而file_get_contents
函数可以对本地文件进行读取,也可以对远程文件进行读取,例如:
http://127.0.0.1/pikachu/vul/ssrf/ssrf_fgc.php?file=http://192.168.50.130/index.html
http://127.0.0.1/pikachu/vul/ssrf/ssrf_fgc.php?file=file:///c:/windows/system.ini
或者使用 filter 获得页面源码(直接访问只会被当做php文件被执行 详细解释)
http://127.0.0.1/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=test.php
1、禁止跳转
2、禁用除http和https外的协议,如:file://
、gopher://
、dict://
等。
3、限制请求的端口为http常用的端口,如 80、443、8080。
4、统一错误信息,避免用户可以根据错误信息来判断远程服务器的端口状态。
5、对请求地址设置白名单或者限制内网IP,以防止对内网进行攻击。
参考文章:
https://cloud.tencent.com/developer/article/1561355
https://www.cnblogs.com/DxyG/p/13742430.html
https://www.cnblogs.com/dogecheng/p/11652022.html#2605005798
https://cloud.tencent.com/developer/article/1587012