本文由红日安全成员: MisakiKata 编写,如有不当,还望斧正。
大家好,我们是红日安全-Web安全攻防小组。此项目是关于Web安全的系列文章分享,还包含一个HTB靶场供大家练习,我们给这个项目起了一个名字叫 Web安全实战 ,希望对想要学习Web安全的朋友们有所帮助。每一篇文章都是于基于漏洞简介-漏洞原理-漏洞危害-测试方法(手工测试,工具测试)-靶场测试(分为PHP靶场、JAVA靶场、Python靶场基本上三种靶场全部涵盖)-实战演练(主要选择相应CMS或者是Vulnhub进行实战演练),如果对大家有帮助请Star鼓励我们创作更好文章。如果你愿意加入我们,一起完善这个项目,欢迎通过邮件形式(sec-redclub@qq.com)联系我们。
- SSRF漏洞
1.1 漏洞简介
SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种利用漏洞伪造服务器端发起请求。一般情况下,SSRF攻击的目标是从外网无法访问的内部系统。
1.2 漏洞原理
通过控制功能中的发起请求的服务来当作跳板攻击内网中其他服务。比如,通过控制前台的请求远程地址加载的响应,来让请求数据由远程的URL域名修改为请求本地、或者内网的IP地址及服务,来造成对内网系统的攻击。
1.3 漏洞危害
1.3.1 扫描内网开放服务
1.3.2 向内部任意主机的任意端口发送payload来攻击内网服务
1.3.3 DOS攻击(请求大文件,始终保持连接Keep-Alive Always)
1.3.4 攻击内网的web应用,例如直接SQL注入、XSS攻击等
1.3.5 利用file、gopher、dict协议读取本地文件、执行命令等
2. 检测与绕过
2.1 漏洞检测
假设一个漏洞场景:某网站有一个在线加载功能可以把指定的远程图片加载到本地,功能链接如下:
http://www.xxx.com/image.php?image=http://www.xxc.com/a.jpg
那么网站请求的大概步骤应该是类似以下:
用户输入图片地址->请求发送到服务端解析->服务端请求链接地址的图片数据->获取请求的数据加载到前台显示。
这个过程中可能出现问题的点就在于请求发送到服务端的时候,系统没有效验前台给定的参数是不是允许访问的地址域名,例如,如上的链接可以修改为:
http://www.xxx.com/image.php?image=http://127.0.0.1:22
如上请求时则可能返回请求的端口banner。如果协议允许,甚至可以使用其他协议来读取和执行相关命令。例如
http://www.xxx.com/image.php?image=file:///etc/passwd
http://www.xxx.com/image.php?image=dict://127.0.0.1:22/data:data2 (dict可以向服务端口请求data data2)
http://www.xxx.com/image.php?image=gopher://127.0.0.1:2233/_test (向2233端口发送数据test,同样可以发送POST请求)
…
对于不同语言实现的web系统可以使用的协议也存在不同的差异,其中:
php:
http、https、file、gopher、phar、dict、ftp、ssh、telnet…
java:
http、https、file、ftp、jar、netdoc、mailto…
判断漏洞是否存在的重要前提是,请求的服务器发起的,以上链接即使存在并不一定代表这个请求是服务器发起的。因此前提不满足的情况下,SSRF是不必要考虑的。
http://www.xxx.com/image.php?image=http://www.xxc.com/a.jpg
链接获取后,是由js来获取对应参数交由window.location来处理相关的请求,或者加载到当前的iframe框架中,此时并不存在SSRF ,因为请求是本地发起,并不能产生攻击服务端内网的需求。
2.2 漏洞出现点
2.2.1 分享
通过url 地址分享文章,例如如下地址:
http://share.xxx.com/index.php?url=http://127.0.0.1
通过url参数的获取来实现点击链接的时候跳到指定的分享文章。如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞。
2.2.2 图片加载与下