🔐 SSRF 为什么总能打进内网：问题不在“服务器会访问 URL”，而在“它替用户做了网络决策”

很多人第一次听 Server-Side Request Forgery（SSRF）时，会把它理解成“让服务器帮我发一个请求”。这句话没错，但太轻了，真正危险的地方是：服务器站在一个比攻击者更有权限的位置上，它能看到外网看不到的东西，比如内网服务、localhost 上的调试接口、云主机的元数据地址，甚至某些只允许机器访问的管理 API。攻击者自己碰不到这些目标，就骗你的应用去碰。

这类漏洞最常见的入口看起来都很“正常”。比如头像上传支持“从 URL 导入图片”，Webhook 支持“回调地址测试”，爬虫支持“抓取网页摘要”，PDF 生成器支持“渲染远程资源”。产品觉得这是便利功能，开发觉得只是调用一下 HTTP 客户端，结果系统却在无意中变成了一个内网代理。只要目标 URL 来自用户输入，而服务端又没有严格限制它能访问哪里，麻烦就开始了。

为什么它会发生？因为程序经常只检查“这是不是一个合法 URL”，却没有检查“这个 URL 最终会连到谁”。攻击者可以直接填 http://127.0.0.1:8080，也可以用 DNS 解析、302 跳转、IPv6 写法、十进制 IP、甚至 URL 里的用户名密码段来绕过粗糙过滤。更糟的是，很多防守只在字符串层面做黑名单，比如禁掉 localhost，但 127.1、[::1]、内网网段、或者先解析到外网再跳转到内网，照样能进去。你以为你在校验文本，攻击者打的是网络语义。

现实里最危险的一类 SSRF，不是去读某个无聊页面，而是去打云环境的元数据服务。经典例子就是 169.254.169.254。如果应用所在机器能访问这个地址，攻击者可能借 SSRF 拿到临时凭证、实例身份信息、访问密钥，再继续横向移动。这个链条之所以致命，是因为它不需要 RCE，不需要提权，连代码执行都没有，只是“让服务器按你的意思访问了一个地址”。

真正靠谱的防法也不是多写几个 if。核心思路只有两个：第一，别让用户决定完整目标地址，能做成“从固定白名单站点拉取资源”就别做成“随便给我一个 URL”；第二，如果业务确实需要访问外部 URL，就在发请求前和每次跳转后都做解析与校验，拒绝 localhost、内网网段、链路本地地址、保留地址和非 HTTP/HTTPS 协议。再往前一步，出网层也要拦，别让这台应用服务器天然能访问内网敏感段和云元数据。应用层校验会漏，网络层隔离才是最后那道硬墙。

还有一个常被忽略的点：不要自动跟随重定向到任何地方。你本来允许访问 https://example.com/image.jpg，结果它 302 到内网地址，你的客户端如果傻乎乎地继续跟，就等于白名单被绕过了。校验必须针对“最终连接目标”，不是只看第一跳。

🧪 你在审一个“根据用户提供的图片 URL 抓图并生成缩略图”的服务。开发说他们已经禁止了字符串里出现 localhost 和 169.254.169.254，所以 SSRF 已经防住。这个判断对吗？为什么？答案是：

💡 核心记忆：SSRF 的本质不是“代发请求”，而是“让高权限服务器替攻击者访问本不该暴露的网络位置”。

#Security