文章总结： 本文深入剖析云环境下SSRF漏洞的致命威胁，指出攻击者可通过访问169.254.169.254云元数据获取临时凭据，进而接管云账号。文章拆解了三层利用链及IP进制变换、DNS重绑定等绕过手法，结合真实案例说明解析差异导致的数据泄露。最终提出应用层白名单校验、网络层隔离元数据IP、强制启用IMDSv2及IAM最小权限等纵深防御方案，强调必须摒弃黑名单思维。 综合评分： 92 文章分类： 漏洞分析,云安全,内网渗透,实战经验,安全建设
内网沦陷的起点：SSRF 指向云元数据的致命一跳
原创
amuxiaohuo amuxiaohuo
黑客网络安全
2026年8月25日 09:01 广东
在小说阅读器读本章
去阅读
【声明】本文内容仅用于授权安全测试、漏洞研究与防御教育。未经授权对任何真实系统进行测试均属违法行为。请在合法授权范围内使用所述技术。
服务端请求伪造（SSRF）在云原生时代获得了前所未有的杀伤力。过去它只是“读读内网”的低调漏洞，但当应用部署到 AWS/阿里云/腾讯云上，实例元数据服务（IMDS）就藏在 169.254.169.254 这个链路本地地址背后，一个 SSRF 就能直接换出云上的临时凭据，进而横向到整个账号。本文拆解 SSRF 的利用链、云元数据的致命一跳，以及工程化的防御方案。
一、SSRF 的本质与典型入口
SSRF 的核心是：攻击者控制了服务端发起的 HTTP 请求的目标地址。凡是“用户输入一个 URL，服务端去访问”的功能都可能是入口：图片预览、链接预览（微信/Slack 发链接自动展开摘要）、Webhook 配置、PDF 渲染、远程文件导入、RSS 订阅、SSO 回调校验、甚至头像从 URL 上传。
最直白的漏洞代码：
url = request.GET[‘u’] resp = requests.get(url) return resp.content
攻击者传入 u=http://127.0.0.1:6379/，就能探到内网 Redis；传入 u=http://169.254.169.254/，就能访问云元数据。现实里大多数 SSRF 不会这么裸，但只要“用户控制 URL + 服务端发起请求”这一组合存在，就需要仔细审查。
二、利用链的三个层次
第一层：内网端口扫描与服务指纹。通过响应时间、状态码、错误信息差异，攻击者能绘出内网拓扑，找到未授权的管理后台。这一步价值有限但不可或缺，是后续利用的侦察阶段。
第二层：访问只绑定在 127.0.0.1 的内部服务。很多组件默认只监听本地回环：Redis、Memcached、Elasticsearch、各种调试端口、Kubernetes 的 kubelet API、Docker daemon。通过 SSRF 让服务端替自己请求这些端点，相当于绕过了“只允许本机访问”的假设。一个经典例子是通过 SSRF 访问本地 Redis 写入自己的 SSH 公钥或计划任务。
第三层：协议逃逸与云元数据。这是 SSRF 杀伤力的天花板。如果底层 HTTP 客户端支持非 http/https 协议，攻击者可以走 file:// 读本地文件、gopher:// 构造任意 TCP 报文、dict:// 与内网服务握手。而在云环境下，http://169.254.169.254/ 是黄金目标。
三、云元数据：那致命的一跳
云厂商在实例内部提供一个特殊的 HTTP 服务，实例上的任何进程都能通过 169.254.169.254 访问到自己的元数据。这些元数据包括实例 ID、所属网络、用户数据脚本，最关键的是——临时凭据。在 AWS 上，如果实例被分配了 IAM Role，请求 http://169.254.169.254/latest/meta-data/iam/security-credentials/
也就是说：只要拿到一个能访问元数据的 SSRF，就能拿到云上这台机器绑定的 IAM 角色的临时密钥。如果这个角色权限配置得太大（现实中常见到 S3FullAccess、甚至 AdministratorAccess），攻击者拿着密钥就能直接操作云 API，读对象存储里的备份、拉取数据库快照、横向到其他实例——SSRF 就此升级成云上账号沦陷。
在很多真实事件里，元数据接口的访问甚至不需要复杂绕过：目标 URL 校验只看了 host 是否含 evil，但没解析 IP；或者只看了 scheme 是否为 http，但没阻止访问 169.254.169.254。一行 http://169.254.169.254/… 的请求直接打穿。
四、绕过 URL 校验的常见手法
开发者最常见的防御是黑名单或正则校验 host，但 SSRF 绕过技巧多到能写一本图鉴。常见的有：
-
IP 进制变换：169.254.169.254 可以写成 2852039166（整数）、0xA9.0xFE.0xA9.0xFE（十六进制）、0253.0376.0253.0376（八进制）、甚至混合进制。只做字符串匹配的黑名单全部失效。
-
DNS rebinding：注册一个域名，A 记录先指向合法 IP（通过校验），TTL 设为 0，第二次解析时指向 127.0.0.1 或 169.254.169.254。如果校验与请求之间各自做一次 DNS 解析，就会命中 rebinding。
-
URL 解析差异：http://[email protected]/ 在 urllib、requests、curl 的解析结果不同，有的取 host=evil，有的取 host=127.0.0.1。校验用一种解析器、请求用另一种，就会形成差异利用。http://127.0.0.1#@evil/ 之类也有类似效果。
-
重定向：校验通过的 URL 返回 302 跳转到 169.254.169.254。如果 HTTP 客户端默认跟随重定向且不重新校验，黑名单就被绕过。302 跳转还能切换协议（http→file）。
-
IPv6 与 IPv4 映射：::ffff:169.254.169.254、[::ffff:7f00:1] 等形式，校验逻辑如果没有正确归一化，会被绕过。
五、防御：从黑名单走向白名单
黑名单永远补不完，SSRF 的正确防御是白名单 + 网络层双重保险。
应用层：1. 尽可能不直接请求用户指定的 URL，而是让用户提供标识符，服务端从配置表里查到真实 URL。2. 必须请求用户 URL 时，解析出 IP 后做白名单校验（只允许公网 IP 段，拒绝私有、回环、链路本地、保留地址），并用校验后的 IP 直接发请求（避免 DNS rebinding，即“校验哪个 IP 就请求哪个 IP”）。3. 禁用重定向跟随，或跟随时重新走完整校验。4. 用专门的 egress 代理统一出口，在代理上做策略。
网络层：1. 通过安全组/防火墙禁止 Web 实例访问 169.254.169.254。AWS 已经推出 IMDSv2，要求请求带 token 且通过 PUT 获取，SSRF 如果只能发 GET 就无法获取 token，从而无法读元数据。强烈建议所有实例强制启用 IMDSv2。2. Web 实例的安全组只放行出网到必要的白名单域，禁止直接访问内网其他业务段。
云平台层：遵循最小权限原则分配 IAM Role，Web 实例的角色只赋予读取自身资源所需的最小权限，绝不使用 * 或 AdministratorAccess。开启云上的异常 API 调用检测（如 GuardDuty），对来自非预期区域的临时凭据使用行为告警。
六、一个真实链路的复盘
某次授权测试中，目标是一个 SaaS 的“导入在线图片”功能。URL 校验代码用了正则限制 host 必须以 .example-cdn.com 结尾，看似安全。但解析用的是 Python 的 urlsplit，而发请求用的是 requests.get(url)。两者对 http://169.254.169.254#@www.example-cdn.com/ 的解析不同：urlsplit 认为 host 是 www.example-cdn.com（通过校验），requests 实际连接的是 169.254.169.254。
随后访问 /latest/meta-data/iam/security-credentials/ 拿到角色名，再访问角色对应的凭据路径，拿到临时 AccessKey。用这组密钥配置 awscli，列出 S3 桶，发现该角色对整个环境的备份桶有 List+Get 权限，直接下载到包含全部用户数据的数据库备份。从一个图片导入功能，到全量用户数据泄露，整条链路不到一小时。
修复方案：把图片导入改为“用户提交 URL，服务端通过 egress 代理请求”，代理只放行公网且拒绝所有私有/保留 IP；实例切换到 IMDSv2 并强制要求；IAM Role 权限从 S3FullAccess 收敛到只允许访问业务自身桶。三层防御叠加，SSRF 的杀伤面被压到最低。
PDF 渲染与无头浏览器：被忽视的 SSRF 放大器
一个常被低估的 SSRF 入口是“把网页转成 PDF”功能。它背后的实现往往是一个无头浏览器或渲染引擎去访问用户提交的 URL，然后把结果导出为 PDF。这个过程中渲染引擎会执行 JavaScript、加载外部资源、甚至触发重定向，能力远超一个普通的 HTTP 客户端。攻击者可以构造一个页面，在 JS 里 fetch 内网地址并把结果画回 DOM，PDF 导出后内网信息就藏在图片或文本里被带出。
更隐蔽的是 file:// 与本地资源访问：如果渲染引擎没禁用本地文件协议，用户提交的 HTML 里用 iframe 嵌 file:///etc/passwd，导出的 PDF 会直接包含文件内容。防御这类“渲染型 SSRF”要点：渲染引擎以非 root、禁用本地文件协议、限制可访问域白名单的方式运行；渲染进程网络隔离，禁止访问元数据与内网网段；导出的 PDF 在返回用户前做内容审计，扫描内网 IP、密钥特征字符串。
#
SSRF 在云时代是名副其实的“一击致命”漏洞。它的危险性不在漏洞本身多么精巧，而在云元数据这个放大器——一个不起眼的 URL 请求，就能换出整个云账号的钥匙。防御它的核心是把黑名单思维换成白名单思维，并在应用、网络、云平台三层叠加管控。尤其要记住：IMDSv2 是云上 SSRF 防御的关键基石，任何还在用 IMDSv1 的实例都应当被视为待修高危项。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：黑客网络安全 amuxiaohuo amuxiaohuo《内网沦陷的起点：SSRF 指向云元数据的致命一跳》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论