SSRF漏洞

SSRF 即Server-Side Request Forgery
服务器端请求伪造攻击,利用漏洞伪造服务器端发起请求,从而突破客户端获取本身得不到的数据,SSRF攻击的目标是从外网无法访问的内部系统。

SSRF漏洞形成的原因主要是服务器端所提供的接口中包含了所要请求的内容的URL参数,并且未对客户端所传输过来的URL参数进行过滤。

假设A网站是一个所有人都可以访问的外网网站,B网站是一个他们内部的网站,普通用户只能访问A网站,不能访问B网站,但是我们可以通过A网站做中间人,伪造身份发送请求,就可以访问B网站,近而达到攻击B网站的目的。
www.shiyanbar.com/xxx.php?image=www.abc.com/.jpg 获取a网站一个图片
那么这里如果服务器端没有对请求获取图片的参数 image 做出严格限制和过滤,那么它就有可能导致获取其它服务器数据
www.shiyanbar.com/xxx.php?image=XXX //XXX为利用方法

可能出现的地方

1
2
3
4
5
6
7
8
9
10
11
12
13
1.社交分享功能:获取超链接的标题等内容进行显示
2.转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览
3.在线翻译:给网址翻译对应网页的内容
4.图片加载/下载:例如富文本编辑器中的点击下载图片到本地;通过URL地址加载或下载图片
5.图片/文章收藏功能:主要其会取URL地址中title以及文本的内容作为显示以求一个好的用具体验
6.云服务厂商:它会远程执行一些命令来判断网站是否存活等,所以如果可以捕获相应的信息,就可以进行ssrf测试
7.网站采集,网站抓取的地方:一些网站会针对你输入的url进行一些信息采集工作
8.数据库内置功能:数据库的比如mongodb的copyDatabase函数
9.邮件系统:比如接收邮件服务器地址
10.编码处理, 属性信息处理,文件处理:比如ffpmg,ImageMagick,docx,pdf,xml处理器等
11.未公开的api实现以及其他扩展调用URL的功能:可以利用google 语法加上这些关键字去寻找SSRF漏洞
一些的url中的关键字:share、wap、url、link、src、source、target、u、3g、display、sourceURl、imageURL、domain……
12.从远程服务器请求资源(upload from url 如discuz!;import & expost rss feed 如web blog;使用了xml引擎对象的地方 如wordpress xmlrpc.php)

绕过方法

1、更改IP地址写法
因为可能通过过滤掉内网IP的方式。
可以通过进制绕过:
192.168.0.1的各种进制

1
2
3
4
5
6
7
(1)、8进制格式:0300.0250.0.1

(2)、16进制格式:0xC0.0xA8.0.1

(3)、10进制整数格式:3232235521

(4)、16进制整数格式:0xC0A80001

2、利用解析URL所出现的问题
在某些情况下,后端程序可能会对访问的URL进行解析,对解析出来的host地址进行过滤。这时候可能会出现对URL参数解析不当,导致可以绕过过滤。
http://www.baidu.com@192.168.0.1/
当后端程序通过不正确的正则表达式(比如将http之后到com为止的字符内容,也就是www.baidu.com,认为是访问请求的host地址时)对上述URL的内容进行解析的时候,很有可能会认为访问URL的host为www.baidu.com,而实际上这个URL所请求的内容都是192.168.0.1上的内容。
3、URL跳转绕过:http://www.hackersb.cn/redirect.php?url=http://192.168.0.1/
4、利用302跳转
xip.io来绕过:http://xxx.192.168.0.1.xip.io/ == 192.168.0.1 (xxx 任意)
指向任意ip的域名:xip.io(37signals开发实现的定制DNS服务)
192.168.0.1.xip.io,就会自动重定向到192.168.0.1。

例子

easygallery-1

查看源码,发现“flag”:
接着在下面发现链接:
http://xxxx/gallery.php?path=http://127.0.0.1:8082/gallery/static/img/portfolio-1.jpg

SSRF利用,直接payload拿试试:
http://xxxx/gallery.php?path=file:///flag

发现为空,这里忽略了一个点:
题目应该是限制了后缀jpg,尝试绕过,这里用到一个点,即%23或?,HTML中起连接作用,而且不影响读取文件

最终payload:
http://xxxx/gallery.php?path=file:///flag%23.jpg

easygallery-2

与1基本类似,但是再次用原来payload会发现报错:scheme error!
猜测后端禁用了file协议。。。

抓包发现是POST方式,猜测是命令执行
最终payload:
http://xxxx/download.php?f=http://127.0.0.1/download.php file:///flag 1.jpg

漏洞修复

1.禁止跳转

2.过滤返回信息,验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。

3.禁用不需要的协议,仅仅允许http和https请求。可以防止类似于file://, gopher://, ftp:// 等引起的问题

4.设置URL白名单或者限制内网IP(使用gethostbyname()判断是否为内网IP)

5.限制请求的端口为http常用的端口,比如 80、443、8080、8090

6.统一错误信息,避免用户可以根据错误信息来判断远端服务器的端口状态。

参考资料:https://www.freebuf.com/articles/web/135342.html
https://xz.aliyun.com/t/2115

-------------本文结束感谢您的阅读-------------
/*
*/