最新资讯

  • 从Host头突破到服务器提权：SSRF+任意文件写入组合漏洞的全链路实战解析

从Host头突破到服务器提权：SSRF+任意文件写入组合漏洞的全链路实战解析

2026-01-31 01:41:15 栏目：最新资讯 1 阅读

在Web渗透测试与网络安全攻防对抗中，单一漏洞的利用价值正被逐步压缩，而由基础请求头管控疏漏引发的组合漏洞攻击，因其隐蔽性强、利用链路长、防御难度大，已成为黑产攻击和内网渗透的核心手段。Host头作为HTTP协议的基础头域，承载着请求目标的核心信息，却常因开发人员的“惯性忽视”，成为串联多个高危漏洞的关键突破口。本次实战中，笔者针对某企业云原生内网业务系统开展渗透测试，从Host头的基础校验疏漏切入，逐步挖掘出服务端请求伪造（SSRF）、任意文件写入两大高危漏洞，通过全链路的漏洞串联与精准利用，最终实现从外网无权限访问到服务器root权限控制的突破。

本文将完整还原漏洞挖掘的思考路径、实战利用的细节操作、漏洞形成的底层逻辑，并结合当前网络安全攻防的新趋势，给出可落地、可迭代、具备前瞻性的防御体系建设方案，为安全测试人员和开发运维人员提供实战参考。

一、测试背景与全维度信息收集

本次测试目标为某企业部署在私有云的业务管理后台系统，该系统为内网核心应用，仅对企业办公网开放访问，外网需通过VPN认证后才可进入，属于典型的“内网高价值目标”。测试前期，笔者遵循**“由外到内、由浅入深”**的探测原则，通过多维度信息收集手段，完成对目标系统的全画像梳理，为后续漏洞挖掘奠定基础，核心探测过程与结果如下：

  1. 网络层探测：通过端口扫描、存活主机探测，发现目标开放80/443（Nginx反向代理）、8080（Tomcat应用服务，内网仅本机可直连）、9000（PHP-FPM，为附属静态服务）端口；通过路由追踪与内网网段探测，确定目标所在内网段为192.168.10.0/24，周边存在数据库、文件服务器等多台核心设备。
  2. 服务层指纹识别：通过技术指纹探测工具与手工验证，确定系统架构为Nginx 1.20 + Tomcat 9 + MySQL 8.0，后端开发语言以Java为主，少量附属模块使用PHP开发；Web容器未做版本脱敏，暴露Nginx 1.20存在的低版本漏洞隐患，Tomcat未配置远程访问限制，仅做了简单的IP白名单过滤。
  3. 应用层接口与目录探测：通过目录爆破、接口模糊测试、被动爬虫等手段，发现系统核心接口集中在/api/v1/目录下，包含系统信息、日志管理、文件操作、用户权限等功能模块；后台登录页为/admin/login，需验证码+账号密码双重认证，暂未发现弱口令与验证码绕过漏洞；存在/upload/（文件上传）、/sys/log/（日志查看）、/file/save/（文件保存）等高危功能接口，其中/upload/做了严格的文件类型、文件头、大小校验，且开启了文件重命名，暂无法直接实现文件上传漏洞利用。
  4. 请求头与交互特征探测：通过对未登录状态下可访问的公开接口（如/api/v1/getSystemInfo、/api/v1/health）进行抓包分析，发现系统对Cookie、Token等身份校验头域做了严格控制，但对Host、Referer、X-Forwarded-For等基础请求头未做任何校验与过滤，请求头可随意篡改，且篡改后服务端无任何异常拦截，这一特征成为本次漏洞挖掘的核心切入点。

初步测试中，弱口令、前台文件上传、SQL注入、XSS等常规漏洞均未发现可利用点，因此笔者将测试重点转向请求头层面的深度挖掘，尤其是被开发人员忽视的Host头。

二、漏洞发现：从Host头篡改到SSRF漏洞的精准验证

Host头的核心作用是让Web服务器识别当前请求的目标域名/IP，正常情况下，Host头由客户端根据访问地址自动生成，且由反向代理与应用服务做双重校验，但本次测试的目标系统因开发人员的认知疏漏，将未做任何处理的Host头直接用于服务端内部请求逻辑，最终引发SSRF漏洞。本阶段笔者通过分层探测、逐步验证的方式，完成了Host头注入与SSRF漏洞的确认，并挖掘出SSRF的可利用范围与边界。

2.1 Host头校验疏漏的初轮探测

针对未登录状态下可正常访问的/api/v1/getSystemInfo接口（无需身份认证，用于返回系统基础运行状态），笔者通过Burp Suite抓包并篡改Host头，进行多组对比测试，核心测试步骤与结果如下：

  1. 正常请求：Host头为目标合法域名sys.xxx.com，服务端响应时间约100ms，正常返回系统CPU、内存、磁盘等基础信息，响应状态码200。
  2. 无效域名篡改：将Host头改为随机无效域名test-abc-123.com，服务端响应时间约120ms，仍返回正常系统信息，且响应体中出现该无效域名的回显，说明服务端未对Host头的合法性做任何校验。
  3. 内网IP+端口篡改：将Host头改为前期探测到的内网Tomcat端口192.168.10.10:8080，服务端响应时间从100ms骤增至300ms，响应体提示“内部服务连接超时，请检查服务状态”，状态码500；改为内网网关192.168.10.1:80，响应提示“连接成功，无可用数据”，状态码200。
  4. 本地回环地址+非开放端口篡改：将Host头改为127.0.0.1:9999（非开放端口），服务端响应直接超时（超过5s），状态码504；改为127.0.0.1:8080（本地Tomcat端口），响应提示“内部服务访问成功”，状态码200。
  5. 危险协议拼接测试：尝试在Host头中拼接gopher://、dict://等危险协议，如gopher://127.0.0.1:6379，服务端未做协议过滤，直接发起请求并返回“协议访问异常”，说明服务端对内部请求的协议类型无任何限制。

核心判断：服务端会将客户端提交的Host头直接作为内部请求的基础地址，拼接接口路径后发起网络请求，且未对Host头的合法性、请求目标的IP/端口、请求协议做任何过滤与校验，SSRF漏洞验证成立，且该SSRF为无限制型SSRF，可对本地、整个内网段发起任意请求。

2.2 SSRF漏洞的可利用范围深度探测

为明确SSRF漏洞的利用边界，为后续组合漏洞利用提供依据，笔者针对内网常见服务、本地文件、危险协议等维度，开展SSRF可利用性深度探测，核心测试结果如下：

  1. 内网服务访问：可正常访问内网192.168.10.0/24网段内的所有开放端口，包括MySQL（3306）、Redis（6379）、FTP（21）等核心服务，不同服务的访问结果会以明文形式返回在响应体中，可通过响应信息判断内网服务的存活状态与基础配置。
  2. 本地文件协议访问：尝试通过file:///etc/passwd、file:///c/windows/system32/drivers/etc/hosts访问本地文件，服务端返回“访问协议被限制”，说明开发人员仅对file://协议做了简单的黑名单过滤，未做协议归一化处理，存在绕过可能。
  3. 危险协议利用：gopher://、dict://、ftp://等危险协议可正常发起请求，其中gopher://协议可成功向本地Redis服务发送请求，仅因未获取到Redis的认证密码，暂未实现Redis漏洞利用。
  4. 日志写入特征发现：在多次篡改Host头发起请求后，笔者通过服务端的报错信息与接口探测，发现Nginx会将每次HTTP请求的完整信息（包括篡改后的Host头）写入access.log日志文件，日志路径为/var/log/nginx/access.log；同时发现系统存在/api/v1/saveLog接口，该接口可将内部请求的结果保存为本地文件，且未做身份认证，这一特征成为串联SSRF与任意文件写入漏洞的关键桥梁。

至此，笔者已确认目标系统存在无限制型SSRF漏洞，且发现了Host头写入日志、日志保存接口可任意操作的核心线索，为后续任意文件写入漏洞的挖掘与利用奠定了基础。

三、漏洞深挖：从日志写入到任意文件写入的全维度挖掘

在确认SSRF漏洞与Host头写入日志的特征后，笔者将测试重点转向/api/v1/saveLog接口——该接口的核心功能为“将系统内部请求的结果保存至服务器本地文件”，是开发人员为方便系统运维而设计的日志管理接口，却因参数校验缺失、权限管控不当、内容过滤疏漏，成为典型的任意文件写入漏洞。本阶段笔者通过对接口参数的全维度篡改测试，完成了任意文件写入漏洞的验证，并挖掘出多种漏洞绕过方式，明确了漏洞的利用价值。

3.1 saveLog接口的基础功能与参数分析

该接口为POST请求，数据传输格式为JSON，无需身份认证即可访问，核心功能是接收客户端传入的参数，通过SSRF发起内部请求，将请求结果保存至服务器指定路径的指定文件中。接口原始请求参数如下，且所有参数均由客户端可控：

{
  "logName": "system_health.txt",
  "savePath": "/webroot/static/",
  "requestUrl": "/api/v1/health",
  "saveType": "txt"
}

各参数核心含义：

  • logName：待保存的日志文件名，开发人员设计初衷为仅允许保存为txt格式文件；
  • savePath：文件保存的服务器本地路径，默认指向Web根目录下的static文件夹，该文件夹为Web可访问目录，外部可通过域名直接访问其中的文件；
  • requestUrl：服务端需要发起内部请求的接口地址，服务端会通过SSRF漏洞拼接Host头与该参数，发起内部请求并获取结果；
  • saveType：文件保存类型，默认值为txt，开发人员设计初衷为限制文件后缀。

3.2 任意文件写入漏洞的多维度验证

针对接口的四个可控参数，笔者依次开展篡改测试，发现开发人员仅做了表面化的简单过滤，未做参数归一化、特殊字符过滤、路径校验等核心安全处理，最终导致任意文件写入漏洞的形成，核心测试过程与结果如下：

  1. 文件名过滤绕过测试：

    • 直接将logName改为shell.jsp，服务端返回“文件类型不合法，仅允许txt格式”，说明做了简单的后缀黑名单过滤；
    • 尝试空格编码绕过：将logName改为shell.jsp%20.txt，服务端无拦截，返回“文件保存成功”，因Nginx在解析文件路径时，会自动忽略空格后的内容，最终服务器生成的文件为shell.jsp，而非shell.jsp .txt；
    • 尝试00截断绕过：将logName改为shell.jsp%00.txt，服务端同样返回“文件保存成功”，生成文件为shell.jsp，说明开发人员未对URL编码字符做解码处理；
    • 尝试双写后缀绕过：将logName改为shell.jjspsp.txt，服务端无拦截，生成文件为shell.jjspsp，虽无法直接利用，但证明过滤逻辑存在严重疏漏。

  2. 保存路径篡改测试：

    • 将savePath改为/webroot/WEB-INF/（Java Web应用的核心配置目录），服务端返回“文件保存成功”，说明对保存路径无任何校验，可将文件写入服务器任意可写目录；
    • 将savePath改为/root/（服务器root用户目录），服务端返回“权限不足”，说明Web进程为普通用户权限，无root目录的写入权限，后续利用需考虑提权；
    • 将savePath改为/usr/local/tomcat/webapps/ROOT/（Tomcat的默认根目录），服务端返回“文件保存成功”，该目录为高价值Web可访问目录，写入的脚本文件可被Tomcat直接解析。

  3. 请求目标篡改测试：

    • 将requestUrl从内部接口改为本地日志文件路径/var/log/nginx/access.log，服务端返回“请求成功”，说明SSRF可被用于读取服务器本地文件，且开发人员未对requestUrl的请求目标做任何限制；
    • 将requestUrl改为内网其他服务器的文件路径192.168.10.20:/var/log/mysql/mysql.log，服务端可正常发起请求并读取该文件内容，说明该漏洞可被用于内网横向渗透。

  4. 文件内容过滤测试：

    • 向requestUrl对应的接口传入包含