SSRF 漏洞实战：内网探测、云元数据窃取一条龙

文章目录

- [一、SSRF 到底伪造了谁](#一、SSRF 到底伪造了谁)
- 二、常见"一条龙"入口
- [三、内网探测：SSRF 当扫描仪](#三、内网探测：SSRF 当扫描仪)
- - [1. 为什么能探](#1. 为什么能探)
  - [2. 探测在实战中的意义](#2. 探测在实战中的意义)
  - [3. 授权测试怎么做才不添乱](#3. 授权测试怎么做才不添乱)
  - [4. DNS 与绕过思维（防守要懂）](#4. DNS 与绕过思维（防守要懂）)
- [四、云元数据窃取：SSRF 最刺痛云的那一下](#四、云元数据窃取：SSRF 最刺痛云的那一下)
- - [1. 元数据服务是什么](#1. 元数据服务是什么)
  - [2. 为什么说"一条龙"而不是单点洞](#2. 为什么说“一条龙”而不是单点洞)
  - [3. IMDSv1 与 IMDSv2（以 AWS 公开模型为例）](#3. IMDSv1 与 IMDSv2（以 AWS 公开模型为例）)
  - [4. 用户数据与其它敏感项](#4. 用户数据与其它敏感项)
  - [5. 授权验证注意](#5. 授权验证注意)
- 五、一条龙链路的完整叙事（便于汇报）
- 六、防御：真正管用的几层
- - [1. 业务层------能不做远程拉取就不做](#1. 业务层——能不做远程拉取就不做)
  - [2. URL 允许列表](#2. URL 允许列表)
  - [3. 协议白名单](#3. 协议白名单)
  - [4. 网络层](#4. 网络层)
  - [5. 云元数据](#5. 云元数据)
  - [6. 响应处理](#6. 响应处理)
  - [7. 检测](#7. 检测)
  - [8. WAF / RASP](#8. WAF / RASP)
- 七、收尾

SSRF（Server-Side Request Forgery，服务端请求伪造）有一句很形象的概括：

本来该由浏览器去请求的地址，变成了服务器替你去请求。

图片预览、文章抓取、Webhook 测试、PDF 渲染、链接转卡片、仓库导入......这些功能很常见，也很好用。麻烦在于：服务端出网或出内网时，若 URL 完全由用户说了算，服务器就成了攻击者的代理探针------扫内网、撞管理端口、打不上公网却打得进的组件，在云上还能顺手问一句"元数据服务，把临时凭证给我吧"。

一、SSRF 到底伪造了谁

伪造的是服务端的身份与网络位置。

防火墙可能允许应用服务器访问内网 Redis、未鉴权的管理接口、云厂商链路本地元数据；却不允许你的笔记本直接访问。SSRF 让请求从"应用服务器"发出来，于是边界策略被借道。

和 CSRF 别混：

	CSRF	SSRF
谁发请求	受害者浏览器	漏洞服务器
借谁的势	用户 Cookie	服务器网络位置/权限
典型目标	用户态操作	内网、元数据、本地服务

二、常见"一条龙"入口

优先怀疑这些参数名与功能：

url、link、src、target、webhook、callback、feed
头像/图片远程拉取
文档/网页转 PDF、截图服务
健康检查、主动探测
第三方集成"测试连接"

协议也不止 http://：file://、gopher://、dict://、重定向跳转，都可能扩大能力，取决于语言库与取消能力。能禁协议就禁，只留 http/https。

三、内网探测：SSRF 当扫描仪

1. 为什么能探

应用服务器通常位于内网网段，对 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.1 的访问策略，比互联网用户宽。攻击者改 URL 主机为内网 IP 或域名，根据响应时间、状态码、报错片段、页面长度差异，判断端口是否开放、服务是什么。

2. 探测在实战中的意义

不是为了"扫全 C 段很酷"，而是为了找：

未授权 Redis / 数据库 / 弹性控制台；
仅内网可达的管理后台；
Kubernetes 管理接口、云厂商内网组件；
本机 127.0.0.1 上的调试端口。

一旦找到未鉴权服务，危害可能从 SSRF 升级到 RCE 或数据泄露------根因仍是内网服务裸奔 + SSRF 入口。

3. 授权测试怎么做才不添乱

限速，避免把内网扫瘫；
先证明确可打到回环或已知测试服务；
记录可访问的敏感网段类型，而不是输出完整活端口字典给无关人员；
推动内网服务鉴权与网络分段，而不只是修一个参数。

4. DNS 与绕过思维（防守要懂）

攻击者可能用：

十进制/异形 IP、短地址；
域名先解析到公网再改到内网（DNS Rebinding，定时条件更苛刻）；
302 跳到内网；
大小写、稀有解析差异。

因此防御不能只写 startsWith("http") 且不含 10. 这种幼稚过滤，要解析后校验、禁跳转或校验跳转目标、统一出站代理策略。

四、云元数据窃取：SSRF 最刺痛云的那一下

1. 元数据服务是什么

云主机（EC2、CVM、ECS 等）上常有一个链路本地 地址，供实例查询自身信息：主机名、用户数据、临时凭证 等。经典讨论最多的是类似 http://169.254.169.254/ 这类地址（各云路径不同）。

设计意图：应用合法取临时角色凭证，免填长效密钥。

SSRF 风险：用户若能让服务器去请求该地址，就可能读到本应只有实例本地能拿的凭证，再拿凭证调云 API------列存储桶、读密钥、建高权限用户，取决于角色权限。

这就是"一条龙"里最吓人的那截：SSRF → 元数据 → 临时密钥 → 云 API。

2. 为什么说"一条龙"而不是单点洞

text 复制代码

① 业务存在 URL 拉取类功能（入口）
② 无严格出站限制，能访问链路本地/内网（网络）
③ 元数据服务可被简单 GET 打到（尤其旧版无会话头校验的模式）
④ 实例角色权限过大（权限）
⑤ 凭证可在实例外使用（身份）

只修 ① 也能救急；要从架构上变难，需要 ②③④⑤ 一起收。

3. IMDSv1 与 IMDSv2（以 AWS 公开模型为例）

AWS 等云厂商推进了更安全的元数据访问方式：需要先拿会话 token（PUT 等），再带头发请求。这让单纯的 SSRF GET 难直接拖走凭证。

运维侧应：

强制较新的元数据服务模式（如仅 IMDSv2）；
给实例角色最小权限；
敏感负载甚至考虑无角色或极窄角色。

其它云有各自的元数据安全机制与加固文档，原则相通：默认难取、权限最小、网络可观测。

4. 用户数据与其它敏感项

元数据里除了凭证，还可能有启动脚本、密钥残留、内部域名。SSRF 读到用户数据同样危险。清理镜像与用户数据中的秘密，和防 SSRF 一样重要。

5. 授权验证注意

在自有实验账号演示"能读到元数据"时，使用最小角色，读完即轮换，勿把真实密钥贴进报告附件。客户环境中，能证明"请求可达元数据地址且返回结构异常敏感"时，优先停机修复与角色收敛，而不是继续用偷来的权限做横向炫耀。

五、一条龙链路的完整叙事（便于汇报）

用故事板给领导或开发讲：

攻击者在"导入链接预览"处提交内网或元数据 URL；
应用服务器发起请求；
先探测到内网某未授权服务（可选分支）；
或直接读到云临时凭证；
用凭证访问对象存储/计算 API；
数据外泄或资源被挖矿。

修复汇报时对应四张牌：入口校验、出站管控、元数据加固、角色收敛。 只说"我们过滤了 169.254"而不做角色收敛，仍会在下一次绕过后重演。

六、防御：真正管用的几层

1. 业务层------能不做远程拉取就不做

能让浏览器直传的，别经服务器中转。必须中转时，进入统一"出站访问服务"。

2. URL 允许列表

只允许访问企业配置过的域名集合；拒绝 IP 字面量（看业务）；禁止内网与链路本地网段。

校验要在解析之后做，并防 DNS 再绑定；限制重定向次数与目标。

3. 协议白名单

仅 https（或 http 也严格），禁用 file/gopher/dict 等。

4. 网络层

应用节点对 169.254.169.254、内网管理段默认拒绝，仅对必要固定目标放行。

出站经代理，代理侧做策略与审计。

5. 云元数据

强制加固模式（如仅 v2）；角色最小权限；敏感实例单独账号与网络。

6. 响应处理

不要把内网服务的原始响应全文回给用户；统一错误信息。减少"用响应内容当布尔探针"。

7. 检测

应用日志记录出站 URL（注意脱敏）；对访问元数据地址、异常内网网段的请求告警；云侧监控异常角色调用（陌生 IP 用临时密钥）。

8. WAF / RASP

可拦一批明显的元数据 IP 与内网地址，辅防而已；编码与跳转能绕字符串规则。

七、收尾

SSRF 的可怕，不在于 payload 花哨，而在于它借用了你最信任的那台机器的网络身份。内网探测揭示分段与鉴权失败；云元数据窃取揭示"临时凭证其实是高权限钥匙"。一条龙能走通，往往是功能图省事 + 网络默认通 + 角色过大的合力。

防守请记住更短的一句：

用户可控的 URL，只能打到你点头同意的目的地；
元数据要难取，角色要最小，出站要可审计。

今晚若只做一件事：搜代码里所有 HTTP 客户端出站，列出"URL 是否用户可控"；同时查云主机是否强制安全元数据模式、角色权限是否宽得离谱。

这两件事做完，你对 SSRF 一条龙的防御，就已经从口头对齐变成了可执行的排查。