一个SSRF漏洞，通过探测让我摸到了内网的什漏“家底”

去年测试某个政府网站，它的洞可到内“图片预览”功能允许输入URL。我随手填了`http://127.0.0.1:8080`，直接页面居然返回了Tomcat默认报错页——端口开着。信息再试`http://192.168.1.1`，通过探测直接弹出了路由器登录框。什漏那一刻我就知道，洞可到内这站点的直接服务端根本没做任何内网地址过滤，SSRF漏洞实锤了。信息这类漏洞的通过探测可怕之处在于：**你不需要任何内网权限，只要一个能发请求的什漏输入框，就能把内网的洞可到内IP、端口、直接服务版本扫个遍**。信息

但SSRF只是“敲门砖”。真正让内网信息“裸奔”的，是配合了**云环境元数据服务**。阿里云、腾讯云、AWS的虚拟机都有一个固定IP：`169.254.169.254`。攻击者顺着SSRF访问这个地址，能直接拿到云账号的临时密钥、实例的角色权限、甚至OSS存储桶的访问凭证。我见过最离谱的一个案例，某公司用SSRF漏洞拉取到了`/latest/meta-data/iam/security-credentials/`下的JSON文件，里面躺着AccessKey ID和SecretKey——那等于把整个云上资产的管理员钥匙交了出来。内网拓扑、数据库密码、运维后台地址，全都可以从这些凭证逆向推出来。

另一个高频入口是**错误配置的Redis或Memcached**。它们默认监听内网端口，如果管理员偷懒没设密码，攻击者只要从外网打穿一台跳板机（比如利用Webshell），就能用`redis-cli -h 内网IP`直接连上。更狠的是，Redis支持`CONFIG SET dir`和`dbfilename`，可以往Web目录写一句话木马。我朋友做过一次渗透测试，就靠着Redis未授权，往对方服务器上写了公钥，直接SSH登录——然后`ifconfig`一看，内网段还有200多台机器。他用了两小时，把整个内网的存活主机、开放端口、运行服务全列成了表格，比管理员自己还清楚。

别忘了**DNS区域传送（AXFR）**。很多老运维根本不知道DNS服务器允许外部请求`AXFR`，以为只要域名解析正常就完事。攻击者用`dig @目标DNS服务器 example.com AXFR`，如果返回了完整记录，内网所有主机名、IP对应关系、甚至VPN网关地址都会暴露。有一次我测某金融机构，一条AXFR请求返回了300多条记录，里面清楚标注了`jump-server.prod.internal`、`db-master-01`——连业务逻辑都猜得八九不离十。这类漏洞不需要代码能力，纯粹是配置疏忽。

还有个容易忽略的点：**Web应用的报错页面**。很多框架（如Spring Boot的Whitelabel Error Page）在异常时会把完整的堆栈信息打印出来，里面藏着内网IP、数据库连接串、甚至Redis的密码。我见过一个Java应用，报错时直接把`application.yml`里的配置项泄露了，`spring.redis.host=10.0.0.8`、`spring.datasource.password=admin123`——全在页面上。攻击者连扫描都省了，直接照着配置去连内网服务。

最后说个反直觉的：**通过外网能直接探测内网**，靠的是“时间差”。比如你向目标的外网服务器发送一个需要解析内网域名（如`internal.company.com`）的请求，如果它响应时间明显变长（因为要查内网DNS），就说明这个域名存在。再结合Nmap的`--script dns-brute`，可以暴力枚举内网子域名。虽然不直接给数据，但能画出内网的结构图——哪些服务在哪些网段，一目了然。攻击者有了地图，后续打点就精准多了。

说白了，内网信息泄露的根子，不在漏洞多高级，而在**信任边界模糊**。开发觉得内网是安全的，把密钥写死在代码里；运维图省事，把Redis暴露在公网；云厂商给了元数据接口，却没人告诉业务方要限制访问。最讽刺的是，这些漏洞几乎都能通过“默认配置”触发——你越懒，攻击者越开心。下次写代码前，先问问自己：如果这个接口被外网直接访问，我能接受什么后果？答案往往比漏洞本身更让人后背发凉。