SSRF：让服务器替你访问内网的那类漏洞

任何「让服务端去访问一个 URL」的功能都可能是 SSRF：图片抓取、Webhook、PDF 渲染、URL 预览。

攻击者要的不是那个页面，而是通过服务器进入内网、读取云元数据、探测内部端口。

先说结论

网络层出网白名单为主，协议与地址校验为辅。 只做字符串黑名单一定被绕。

• 禁掉非 http/https 协议（file、gopher、dict）
• 解析后的 IP 必须校验，不能只校验域名
• 禁访问私有网段与云元数据地址
• 出网走代理并做白名单

漏洞是怎么产生的

SSRF 的绕过手法围绕「解析差异」：域名解析到内网 IP、十进制/八进制 IP、302 跳转、DNS 重绑定。

所以校验要发生在「实际连接前解析出的 IP」上，而不是原始字符串。

修复与验证

修复不是改一行代码，而是四件事一起做：

• 列出所有由外部控制 URL 的功能点
• 只允许 http/https，禁用重定向或限制跳转次数
• 解析域名得到 IP 后校验：拒绝私有网段、回环、链路本地、云元数据地址
• 出网统一走代理，代理侧做域名白名单
• 云上关闭实例元数据 v1，改用需要 token 的 v2

攻击面与检测点

按影响面排序，先修影响最大的：

几个容易踩的坑

下面这些是最常见的错误做法：

• 只校验域名后缀：解析到内网照样通
• 校验一次就发起请求：中间还可能跳转
• 忽略云元数据：169.254.169.254 可拿到临时凭证
• 把内网请求当成可信：内网也有横向风险

写在最后

SSRF 是网络问题，最好在网络层解决：默认不出网，需要出网的走白名单代理。

安全不是一次加固，是持续的假设：假设输入不可信、假设边界会破、假设有人会看错。