记一次404页面到ssrf的漏洞挖掘

原创

ss
ss

shadowsec

2026年10月18日 13:41
河南

去阅读

说到404，最常见的就是springboot的whitelabel error page了。这个页面并不代表服务不可用，恰恰相反，它说明 SpringBoot 应用已经部署启动成功，只是当前请求没有匹配到对应的路由。

拼接上常见spring接口，测试地图就到手了。

到这里就能发现：404不只是一个简单的HTTP状态码，不同场景下返回的404，会透出完全不一样的信息。比如有的直接回显Whitelabel，说明应用活着只是缺路由。有的响应里回{\"code\":404,\"upstream\":\"...\"}这种带upstream 字段的JSON，说明请求命中了后端/xxx，只是Host头/域名校验未通过，导致被网关拦截。有的直接回显的Tomcat,IIS的版本号，很明显是容器行为，可以顺着版本尝试nday。当然也有无任何信息的，大概率做的是反代（这里借用下截图）

针对 Nginx 这类无特征的404，可以用Google、Bing的site: 语法去找被收录的url。再逐个访问，看哪些还能打到真实业务

也可以通过wayback machine回溯历史快照，抓取历史js文件，访问路径，robots.txt记录。

https://web.archive.org/cdx/search/cdx?url=example.com/*&fl=original,timestamp,statuscode&collapse=urlkey

如果这些都没有收获，再用精简字典补一轮。

最近和表哥渗透遇到个系统，用工具扫完之后筛资产，前期大部分子域名都没什么收获，最后转向一个只回 404的页面，想再挖一挖。访问域名返回：

{\"code\":404,\"message\":\"Not Found\"}

正常的404页面基本都是html，这里回的是json，第一感觉是它接了统一的异常处理。抓包观察响应，发现里面携带了多个自定义响应头，其中一个自定义头直接泄露了网关产品名称。

平时遇到比较通用的可能就先跳过了，但是这个很小众。通过网关名进行互联网检索，在csdn一篇文章中发现在过去该网关作为试验产品开源过，且邀请共同维护并附上了开源github链接。说明是自研且有源码

访问github链接代码仓库已经清理

但原仓库清理，过去一起维护的其他人呢？面对这种产品我一直相信有人会fork下来。通过多角度搜索github仓库，终于在一个角落发现了一个fork版本。把源码拉下来和线上对了一下，发现只有少量接口对得上。也就是说后续厂家做了很多轮更新。那这条线就断了吗？

通过收集少量代码中的少量接口进行fuzz，发现几个未授权的存在，但是不返回内容。此时再思考网关的存在大概率是需要监控的，监控健康状态、指标等等。那么利用ai生成几个监控常见路径字段，如metric，health，status。批量fuzz之后最终在某个未授权路径下的/metric成功获取了监控的路由整表。

那么这下好办了，拿到全量路由批量探测。但基本都是401状态，即使是响应200的也没返回什么内容。

又重新仔细看了下url，然后发现了一个/xxx/xxx/xxproxy?url=的接口，遇到这种接口很明显，代理url一般就是ssrf高发接口。探针

?url=http://xx.xx.xx.com/latest/meta-data

最终获取了元数据。

这个案例也让我重新审视自己过去的资产筛选规则。之前面对工具扫描出的成千上万的资产。为了快速把有价值的挑出来，所以最初我在第一阶段设定规则就是响应200、存活、有内容。命中的进入下一轮，其他的就丢弃，以至于很多404等资产被忽略。

过去精力有限，一天只能测试几个系统，大部分人都一样，所以成熟的流水线也能让我挖出漏洞。扫全量 JS 与懒加载 chunk，还原 Webpack打包，尽可能捞出接口后批量进入burp测试。而现在AI辅助测试之后，这一流水线速度提升巨大，且更细致。之前的脚本还依靠正则可能会稍微遗漏，要分析前端加解密需要调试花费长时间。现在js面已经扫描的非常干净了，且加解密基本能秒解。速度上来了，同样的时间能覆盖的资产也成倍增加。依照旧规则获取的业务系统很大概率已经被别人扫描测试，再加上打法又高度趋同，那么就只剩下拼手速。在这样的情况下，很明显之前资产收集的规则需要重新规划，挖掘更多的隐藏资产。之前的404等资产也应该接入到目标资产里来，不怕杂更怕少，杂不烧心。