文章目录一、SSRF 到底伪造了谁二、常见“一条龙”入口三、内网探测SSRF 当扫描仪1. 为什么能探2. 探测在实战中的意义3. 授权测试怎么做才不添乱4. DNS 与绕过思维防守要懂四、云元数据窃取SSRF 最刺痛云的那一下1. 元数据服务是什么2. 为什么说“一条龙”而不是单点洞3. IMDSv1 与 IMDSv2以 AWS 公开模型为例4. 用户数据与其它敏感项5. 授权验证注意五、一条龙链路的完整叙事便于汇报六、防御真正管用的几层1. 业务层——能不做远程拉取就不做2. URL 允许列表3. 协议白名单4. 网络层5. 云元数据6. 响应处理7. 检测8. WAF / RASP七、收尾SSRFServer-Side Request Forgery服务端请求伪造有一句很形象的概括本来该由浏览器去请求的地址变成了服务器替你去请求。图片预览、文章抓取、Webhook 测试、PDF 渲染、链接转卡片、仓库导入……这些功能很常见也很好用。麻烦在于服务端出网或出内网时若 URL 完全由用户说了算服务器就成了攻击者的代理探针——扫内网、撞管理端口、打不上公网却打得进的组件在云上还能顺手问一句“元数据服务把临时凭证给我吧”。一、SSRF 到底伪造了谁伪造的是服务端的身份与网络位置。防火墙可能允许应用服务器访问内网 Redis、未鉴权的管理接口、云厂商链路本地元数据却不允许你的笔记本直接访问。SSRF 让请求从“应用服务器”发出来于是边界策略被借道。和 CSRF 别混CSRFSSRF谁发请求受害者浏览器漏洞服务器借谁的势用户 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. 为什么说“一条龙”而不是单点洞① 业务存在 URL 拉取类功能入口 ② 无严格出站限制能访问链路本地/内网网络 ③ 元数据服务可被简单 GET 打到尤其旧版无会话头校验的模式 ④ 实例角色权限过大权限 ⑤ 凭证可在实例外使用身份只修 ① 也能救急要从架构上变难需要 ②③④⑤ 一起收。3. IMDSv1 与 IMDSv2以 AWS 公开模型为例AWS 等云厂商推进了更安全的元数据访问方式需要先拿会话 tokenPUT 等再带头发请求。这让单纯的 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 一条龙的防御就已经从口头对齐变成了可执行的排查。