Server-Side Request Forgery(服务器端请求伪造)
这是在2021年中新出的类别,这是种看着不起眼,但是要是配置不当,就容易引发严重的后果.
SSRF 定义
SSRF 全称是服务器端请求伪造(Server-Side Request Forgery)
是利用一个服务器向另一个服务器发送请求
还有个极其相似的兄弟叫CSRF(XSRF) , 全称是跨站点请求伪造
也就是伪造使用者身份向目的服务器发送非法请求。
SSRF 流程
我们结合定义和此图,可以理解SSRF的基本流程
但是我们要想一个简单的问题:我们为何不能向主机B直接发送请求呢?
可能一:这个主机B是服务器A所在的内网一种设备,并没有配置外网 IP 。比方说是 SQL 服务器什么的,减轻服务器A的处理压力。
可能二:内网中可能有其他厂家资源,虽然进行了严格的外网限制,但是却对内网所属的服务器没有进行严格的限制。
以我的普通私人服务器为例
腾讯云给了用户一个公网 IP 和内网 IP
其中公网 IP 是对外开放的IP
而内网 IP 是服务器集群里的内部 IP
我可以利用此服务器做哪些操作呢?
-
我可以获取内网下其他服务器的开放端口。有的服务对于外网有严格的访问限制,但对于内网则没有。
-
我们就可以进行内网渗透的操作。
思路拓展:
- 翻译软件的巧用
想要理解 SSRF 就可以巧妙利用翻译软件,下面以有道网页翻译为例
这是我通过站长工具获得的IP.
如果我们在有道上同样输入刚才的IP查询工具
我们可以看见有道的103.72.47.15服务器为我们发送了请求
SSRF 危害
- 隐藏IP
- 进入内网渗透
- 扫描内部网络
- 向内部主机任意端口发送特制数据包
- DOS 请求大文件始终保持连接
- 暴力穷举(users,files等)
- 更好的对已存在的SSRF漏洞进行使用(比方说 SQL ,默认不允许外部访问,但对本地没有防护)
简单样例
首先,我们可以写两个简单的界面
截取界面内容
获取当前访问IP
我们尝试向 index.php 加上百度官网试试
我们可以看出正常显示百度官网的首页
我们再访问下我们刚写的 11.php 试一下
成功获取我的当前IP
我们想一下,把baidu换成11.php会发生什么?
就变成了我的服务器IP,因为请求是由我服务器发送的
如果把IP换为我内网IP会如何呢?
可以看出服务器是通过内网 IP 向我服务器发送请求
通过这些简单的样例,是不是理解了我前面说的话 , 只要我知道目标机器的内网 IP , 我就利用某些服务对于内网不设防护的漏洞来进行渗透 . 或者是利用 file 等其他协议获取文件等 .
来点实例
上面的简单样例是基于本机 IP 来进行的。
我们就来利用虚拟机模拟个服务器集群
接下来将会讲述如何利用SSRF,进行SQL注入
其中对192.168.31.228的85端口进行了映射,映射到公网 IP的4277端口
而192.168.31.30的83端口并没有进行端口映射,所以外网是无法访问改网址,只能通过内网访问
我们通过4277有SSRF漏洞的界面,输入本机界面
我们可以看见套娃自己,也就是说内网界面不受限制
我们再去访问30里的83让他显示出来
此时我们可以看出内网界面正式显示出一个sql查询界面
我们此时可以进行SQL注入
此时,SQL相关数据已经在上面了
但是,在实际情况中,肯定比这个要复杂的多。我们要考虑这么几个问题
我们是在知道的情况下进行处理的,当我们不知道内网服务器情况的时候该怎么办?
SSRF 仅限于 SQL 注入吗?如果有其他的漏洞又如何利用SSRF来进行攻入?
我们再看一下源代码
我们从这段函数中是调用curl函数进行数据流输出,我们就需要找到curl是如何定义的
这一段便是curl函数的部分,我们理解为交给curl函数时并没有进行任何的URL过滤而直接进行了数据流传输。这也是为何导致SSRF
再看一下造成 SQL 注入的源代码
在这里,开发者并没有对输入的字符进行任何的处理,直接交给数据库进行处理,从而导致了 SQL 注入的可能性
处理方法
- 设置黑名单, 将内网地址给过滤,禁止访问内网
- 限制协议,仅限 HTTP 和 HTTPS 协议
- 限制端口,关闭不常用服务
- 过滤返回信息 , 检测返回信息是否规范 避免信息泄露(比方说网易163首页,检测到 file_get_contents() 或者 curl_init() , 先是正常显示 , 然后变成了白屏 )