内网的漏洞一台服务器上，某个不起眼的复现图片预览功能成了整个内网的突破口。那次演练中，漏洞我传了一个URL进去，复现对方应用居然老老实实地去请求了。漏洞返回的复现响应里，我看到了一个眼熟的漏洞登录页——是内网另一台管理系统的。

这就是复现SSRF，服务端请求伪造。漏洞攻击者让服务器替自己去访问本来访问不到的复现资源。听着玄乎，漏洞原理却简单得像个孩子——你让服务器帮你“看一眼”某个地址，复现它看了，漏洞还把结果告诉了你。复现

复现环境用的漏洞是DVWA加上一个自定义的PHP页面。核心代码就三行：接收参数url，用file_get_contents去请求，然后把内容echo出来。看起来人畜无害，可当url参数变成http://127.0.0.1:8080/admin时，问题就来了。

我先把url设成http://127.0.0.1:22，返回了SSH的banner信息。再试8080端口，直接看到了那个内网管理后台的HTML源码。关键不在于能看到什么，而在于服务器替我做了一次内网探测。端口开放情况、服务类型、甚至内网拓扑，都能通过响应差异一点点摸出来。

更狠的玩法是配合gopher协议。这个协议能构造任意TCP数据包，相当于让服务器当你的跳板机，向内网任意服务发起完整对话。拿Redis举例，通过gopher发送一条写crontab的命令，服务器就会乖乖执行。整个内网沦陷往往就这么开始的。

防护手段其实不复杂。服务端做严格的URL白名单校验，解析完域名后确认IP不在内网段，重定向也要跟着检查。可惜现实里很多开发图省事，直接拿用户输入去请求，连最基本的协议限制都没做。

那次复现结束后，我特意去翻了那个应用的日志。发现它不光请求了内网地址，还尝试访问了云元数据服务的169.254.169.254。这个地址在云环境里能拿到临时密钥，要是真被打通了，后果不敢想。好在演练环境隔离了这部分。

SSRF最讨厌的地方在于，它往往藏在不显眼的业务逻辑里。比如网页截图服务、PDF生成器、甚至URL预检查功能。这些功能天然需要访问外部地址，开发时很难想到会被用来探测内网。我见过不少安全做得挺严的公司，偏偏在这种小功能上栽了跟头。

修起来也不难，但得养成习惯。每次写这种功能前，先问自己一句：这个URL真的需要让用户随便传吗？如果必须传，那就老老实实做好白名单和协议限制。安全这东西，大多数时候就是多写几行校验代码的事，可偏偏有人懒得写。

写完这篇复现笔记，我把测试用的那些请求都清了。下次再碰到类似功能，大概会多留个心眼。