把贴上的 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。
本站把「不替用户保管秘密」「只诊断已确认所有权的目标」「把被攻破时的损害降到最小」作为设计的基础（→ 关于本站）。
SSRF、CSRF 与开放重定向的区别
这三者都涉及由外部指定的目标，但「移动的是什么」以及「能触达多远」各不相同。
| 攻击 | 谁去往哪里 | 能触达什么 |
|---|---|---|
| SSRF | 你的服务器向被指定的目标发出请求 | 从外部无法触达的地方，例如内部网络和云凭据 |
| CSRF | 用户的浏览器发出用户本人并不想发的请求 | 用户在已登录站点上能做的事 |
| 开放重定向 | 用户的浏览器被转到被指定的外部网站 | 假网站（网络钓鱼） |
SSRF 之所以尤其危险，是因为它触达的是「服务器的内侧」。防火墙从外部保护的地方，经由服务器仍然可以触达。
实例：它也潜藏在框架的功能里
SSRF 不只出现在自己编写的「获取这个 URL」功能中，也会出现在框架的功能里。例如在近年 Next.js 的 CVE 中，SSRF（CWE-918）是最常见的弱点类型之一，出现在图片优化这类获取外部图片的服务器功能中（→ 用真实数据看 Next.js 与 React 的漏洞）。在 MITRE 于 2025 年 12 月发布的「CWE Top 25」（最危险的 25 种软件弱点）中，SSRF 位列第 22。
在云环境中，Capital One 事故是标准案例。SSRF 触达了元数据服务，权限过大的临时凭据被窃取。2019 年 11 月，AWS 发布了 IMDSv2，以减轻这类危害。
检查自己环境的方法
列出所有获取外部传入 URL 的地方
在代码中搜索目标可能包含用户输入的 HTTP 客户端（fetch、axios、requests 等）。链接预览、Webhook、图片导入、PDF 生成和导入功能是典型位置。
检查框架的放行设置
在图片优化或外部获取的设置中，确认放行的主机范围没有过宽（对 Next.js 来说，确认 images.remotePatterns 中没有只含通配符的条目）。
强制使用 IMDSv2（AWS）
在每台 EC2 实例的元数据选项中，确认 HttpTokens 为 required（仅限 IMDSv2）。在不运行容器的服务器上，把 token 响应的跳数限制保持为 1。
限制服务器的出站通信
把获取 URL 的代码放在无法触达内部网络的独立环境中运行，或把出站通信限制在所需的目标。即使应用的校验有遗漏，网络层仍能拦下。
参考资料（一手来源）
- OWASP, "Server-Side Request Forgery Prevention Cheat Sheet" — cheatsheetseries.owasp.org（allowlist、阻断内部地址、重定向与 DNS 的处理）
- AWS, "Use the Instance Metadata Service to access instance metadata" — docs.aws.amazon.com（IMDSv2 会话 token、required 设置、跳数限制）
- AWS Security Blog, "Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service"（2019 年 11 月）— aws.amazon.com
- Microsoft, "Azure Instance Metadata Service" — learn.microsoft.com（Azure 同样使用 169.254.169.254）
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses"（2025 年 12 月）— cwe.mitre.org（CWE-918 位列第 22）