记一次基于 Host 头的 SSRF+任意文件写入

在一次攻防演练中，内网没什么可突破的点了，扫了一下办公网，发现了一套 E‑Assets Manager 的“CDN 节点资源同步系统”的测试环境，应该是开发在本地搭的环境，所以有一些意外的漏洞点。

文章作者：先知社区（guchangan1）

文章来源：https://xz.aliyun.com/news/91292

1►

测试过程

登录后台后，发现一处功能点，节点资源同步，开发目前做的demo，只能将本机节点的资源同步到本地，估计未来的功能点就是将其他节点的静态资源同步到本地。

抓包过程中发现实际上就是通过file参数远程请求URL资源

如下，当资源不存在的时候，返回同步失败

当资源存在时，会进行同步，并且落地到/downloaded_files/目录

并且web目录可以直接访问到落地的文件

我们正常的思路就是测file参数能否进行任意文件下载，但实际上并不太行，因为这里压根就是将URL+file拼接起来去做远程下载。

测试过程中意外发现，我们可以固定好真实HOST头，修改HOST头为我们服务器的地址，发现居然可以直接远程请求到。

那这里就是一处基于HOST头的SSRF了，我们在服务器监听一个jsp文件，远程请求即可落地

2►

后续代码分析

拿了shell后简单分析了一波代码，问题有两个：

• 信任 request.getServerName() （Host 头），导致 SSRF

• saveUrl() 把响应内容直接写到本机磁盘，路径/扩展名不受控，甚至可能写到 web 目录 → 任意文件写入/RCE

‍首先看获取到HOST头是通过request.getServerName()，猜测是开发自己搭的本地环境，测试远程请求，所以暂时使用request.getServerName()获取本机的HOST。

SaveUrl也没什么看的，标准的远程连接请求+文件写入

3►

漏洞总结

• 生产环境或许可能不存在这样的漏洞，但在内网扫扫办公网偶尔也能扫到开发本地私搭的不完善的测试web服务。

• request.getServerName() 的来源本质上是来自请求头 Host

• 这个洞的修复核心其实可以一句话概括：不要让客户端（尤其是 Host 头）影响服务端回源的目标地址，把回源目标收敛到配置或后端逻辑；同时保证写入目录和文件类型不可利用。

文章来源：李白，你好