「输入一个 URL，就帮你把里面的内容取回来」——这种随处可见的便利功能，在最坏的情况下会成为云密钥被夺走的入口。这就是 SSRF。本文从零讲解它的原理与防御。
到底发生了什么
正常的访问是「用户 → 外部网站」。而 SSRF 则是把服务器当成代理，让它去访问「内部」。由于服务器能够触达从外部看不见的内部网络，或云的凭据提供端，攻击者就能借此间接窥探这些地方。
169.254.169.254（云凭据）在云环境中，从这个内部目标（元数据提供端）有可能取到 临时凭据。一旦通过 SSRF 到达那里，密钥就会被夺走，进而连锁导致整个存储被导出。这在现实中已经酿成了大规模事故。→ Capital One —— SSRF 导致 1 亿人信息泄露的事件
它潜藏在哪里
「服务器去获取用户输入的 URL」这类功能全都是候选对象。
| 功能 | 常见的实现方式 |
|---|---|
| OG / 链接预览生成 | 服务器获取被贴上的 URL 并生成缩略图 |
| Webhook 发送 | 服务器向用户指定的目标发起 POST |
| 图片・文件导入 | 「从 URL 获取图片」 |
| 网站诊断工具 | 服务器访问所输入的网站并进行检查 |
验证时常被忽略的坑
只做到「拦截内部 IP 就行」是不够的。下面这些绕过路径必须堵住。
只做简单拦截会有漏洞
- 重定向跟随：被允许的域名用
302跳转到内部地址。 - DNS 重新解析（rebinding）：校验时是外部 IP，获取时切换成内部 IP。
- IP 写法的变体：用十进制、八进制、缩写写法等来伪装内部地址。
- 其他协议：
file://或gopher://等意料之外的协议。
功能开发方应有的防御
SSRF 要靠「功能的实现方式」来防御。这也是本站作为安全产品对自家诊断功能所施加的规则。
目标采用 allowlist 方式
将协议（http/https）和主机只限定为已允许的那些。「只放行允许的」比「拦截内部的」更稳妥。
阻断内部目标
拒绝对 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254（元数据）等的访问。
只限已确认所有权的域名（诊断类）
只针对用户已证明所有权的域名。不让它去访问第三方网站。
堵住绕过路径与元数据
对重定向的最终落点也要校验，并考虑 DNS 重新解析。云上则通过 IMDSv2 等方式，让访问元数据必须带 token。
本站把「不替用户保管秘密」「只诊断已确认所有权的目标」「把爆炸半径降到最小」作为设计的基石（→ 关于本站）。
接下来阅读
FAQ
Q哪些功能容易出现 SSRF？
「服务器去获取用户输入的 URL」这类功能。例如 OG 预览生成、Webhook 发送、图片导入、网站诊断工具等。越是便利的功能越需要小心。
Q为什么 SSRF 在云环境中尤其危险？
因为云上的虚拟机有一个仅限内部访问的「元数据提供端」，从那里可能取到临时凭据。一旦通过 SSRF 到达那里，密钥就会被夺走，进而连锁导致整个存储被导出（这正是 Capital One 事故的路径）。
Q如何防御 SSRF？
用 allowlist 严格校验目标，并阻断对内部 IP（127.0.0.1、10.x、169.254.169.254 等云元数据）的访问。如果是诊断类功能，则只限定为「已确认所有权的域名」，同时堵住重定向跟随和 DNS 重新解析的绕过路径。