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

登录后台后，发现一处功能点，节点资源同步，开发目前做的demo，只能将本机节点的资源同步到本地，估计未来的功能点就是将其他节点的静态资源同步到本地。 抓包过程中发现实际上就是通过file参数远程请求URL资源

如下，当资源不存在的时候，返回同步失败 并且web目录可以直接访问到落地的文件

我们正常的思路就是测file参数能否进行任意文件下载，但实际上并不太行，因为这里压根就是将URL+file拼接起来去做远程下载。 测试过程中意外发现，我们可以固定好真实HOST头，修改HOST头为我们服务器的地址，发现居然可以直接远程请求到。 那这里就是一处基于HOST头的SSRF了，我们在服务器监听一个jsp文件，远程请求即可落地

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

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

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

首先看获取到HOST头是通过request.getServerName()，猜测是开发自己搭的本地环境，测试远程请求，所以暂时使用request.getServerName()获取本机的HOST。 SaveUrl也没什么看的，标准的远程连接请求+文件写入

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

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

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

免责声明

1.一般免责声明：本文所提供的技术信息仅供参考，不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》，作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。

2. 适用性声明：文中技术内容可能不适用于所有情况或系统，在实际应用前请充分测试和评估。若因使用不当造成的任何问题，相关方不承担责任。

3. 更新声明：技术发展迅速，文章内容可能存在滞后性。读者需自行判断信息的时效性，因依据过时内容产生的后果，作者及发布平台不承担责任。

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）