跳到正文
ITDWeb 安全平台
ITD
搜索

安全事故与漏洞

严重#SSRF#云#IAM#AWS#企业泄露

Capital One 数据泄露事件（2019）— SSRF 如何导致 1 亿人信息外泄及防御之道

2019 年，Capital One 约 1 亿 600 万人的申请数据泄露。SSRF 让攻击者抵达云元数据服务，取得权限过大的 IAM 临时密钥并复制 S3 数据。讲解 IMDSv2、IAM 最小权限与出站白名单等防御。

发布于 2026-06-07 更新于 2026-10-05 4 分钟阅读
本页目录

我们解读真实发生过的公开事故，但视角不是新闻的重播，而是「在你的环境里该如何防住」。本文是 基于公开记录（监管机构、报道、学术分析、官方公告）的解读。出处在文末注明。

1.06亿
受影响人数（美·加）
约14万
社会保障号(SSN)
$80M
美国 OCC 罚款
IMDSv2
此事故推动其推出
事故摘要 / CASE FILE
对象
Capital One（美国大型银行）
公布
2019 年 7 月 29 日（发觉 7 月 19 日／入侵 3 月）
手法分类
以 SSRF 为起点，窃取云端凭证并向外带出
影响规模
美·加约 1 亿 600 万人的申请数据（含 SSN 约 14 万、关联银行账号 约 8 万）
根本原因
SSRF 缺陷 ＋ 元数据服务端点不设防 ＋ IAM 角色权限过大，多层接连崩塌
主要对策
出站目标白名单、IMDSv2、IAM 最小权限构成的多层防御

发生了什么（用大白话讲）

Capital One 把部分申请处理跑在云上。在其前端、本应属于防御方的一个组件（以反向代理／WAF 身份运行）存在 SSRF 缺陷——能让服务器自身向外部指定的目标发起请求。

云端的虚拟机有一个特殊目标，叫只能从内部访问的「元数据服务端点」，向它查询就会返回分配给该机器的权限所对应的临时密钥。攻击者用 SSRF 抵达这个内部目标，拿到了密钥。而该密钥所绑定的 IAM 角色（公开记录中报道为 ISRM-WAF-Role）拥有 可大范围读取存储的过大权限，于是他们把约 700 个存储区域（S3 存储桶）的内容原样复制后带走。

存在 SSRF 时，「只能从内部访问」的端点也能从外部访问

元数据服务端点的防护建立在「外部无法抵达」这一前提之上。然而 SSRF 是一种让服务器自身代为访问的攻击，它会打破这一前提。只要存在一个 SSRF 缺陷，「因为限定内部所以安全」就不再成立。

攻击的各个阶段与拦截方法

关键在于：这是一条四步的连锁，而 每一步都本有拦截点。请不要把它读成攻击步骤，而要读成在哪里本可被拦下。

① 起点：SSRF

让服务器代为向任意目标发起请求的缺陷。

⊘ 拦截点：把出站目标改为白名单方式

↓

② 抵达内部的元数据服务端点

本应限定内部的目标，却被经由 SSRF 抵达。

⊘ 拦截点：IMDSv2（强制令牌＋跳数限制）

↓

③ 取得 IAM 临时密钥

挂在机器上的角色的临时凭证被返回。

⊘ 拦截点：把角色权限最小化（禁止整体读取存储）

↓

④ 把存储(S3)一次性整体复制

把约 700 个区域的内容原样向外带出。

⊘ 拦截点：出站(egress)管控＋检测异常的大量读取

每一步都本可以被拦住。纵深防御意味着设置多个能拦住攻击的环节，而不是只依赖一项控制措施。

已公布的时间线

  1. 2019-03

    云环境遭到非法访问（后来才查明）。

  2. 2019-07-17

    外部举报（GitHub 上的帖子）指出异常。

  3. 2019-07-19

    Capital One 通过内部调查确认遭入侵。

  4. 2019-07-29

    对外公布。一名前 AWS 工程师的嫌疑人被 FBI 逮捕。

  5. 2019-11

    AWS 发布 IMDSv2，作为针对 SSRF 的多层防御。

  6. 2020-08

    美国 OCC 处以约 8,000 万美元罚款，指出其在迁云之前的风险评估存在缺失。

根本原因：多道防御同时缺失

把这起事故归结为「SSRF 的错」，就会重演。实际上其本质是 三道防御接连失守。

失守的构成（事故当时）

  • 入口处不校验出站目标（可向任意目标代为发起请求）
  • 元数据服务端点无需令牌就返回密钥（旧方式）
  • 机器的 IAM 角色拥有可大范围读取存储的过大权限

守住的构成（杜绝重演）

  • 把出站目标限定为白名单方式，拒绝对内部地址的代为访问
  • 元数据采用 IMDSv2：强制会话令牌＋跳数限制，阻断代为抵达
  • IAM 角色采用最小权限：只给所需存储桶上所需的操作

责任共担：云端使用方必须自己负责的部分

云一方负责底层基础设施的安全，但修复 SSRF、设计 IAM 权限、保护元数据是使用方的责任。这起事故被处罚的理由也是「迁云之前的风险评估存在缺失」。使用云本身并无问题，关键在于是否把属于自己责任的部分彻底设计到位。

在你的环境中杜绝重演

以下是无论规模大小都奏效、按优先级排列的对策。只要你有哪怕一个「接收 URL 并去拉取」「代为获取 Webhook 或图片」的功能，这就是你自己的事。

1

把出站目标改为「白名单方式」（在第一步拦住 SSRF）

对于服务器代为访问用户提供的 URL 的处理，要限定为仅限已许可的目标。对内部地址（元数据服务端点或私有网络）的抵达默认拒绝。SSRF 词条里汇总了校验时容易漏掉的坑（跟随重定向、DNS 重解析等）。

2

对元数据强制使用 IMDSv2

把云端的元数据服务端点限定为强制令牌、带跳数限制的新方式（AWS 上即 IMDSv2）。仅此一项，就能让从 SSRF 窃取密钥的难度大幅提升。要点是禁用旧方式。

3

把 IAM 角色设为最小权限（限制损失）

为了在密钥万一泄露时把损失控制在有限范围内，给机器或服务挂载的权限要收紧到只给所需对象上所需的操作。「先一股脑给存储全权限」会把一次入侵变成全量数据外泄。

4

准备好出口(egress)管控与异常检测

把外向通信限定到必要的目标，并能检测出诸如短时间内大量读取之类的异常。即便第一步没能防住，也要留下一层能在带出阶段察觉的防线。

与本站设计理念相通之处

本站自身在处理用户 URL 的功能上，也以仅限已验证域名为前提来设计（SSRF-safe by design）。这起事故清楚地说明了我们所坚守的原则为何必要：校验输入、使用最小权限、不要以为「内部」就等于安全。 即便使用便利的云平台，属于自己责任的部分也必须由自己设计到位。

出处（公开记录）

本文的事实依据以下公开信息。我们不涉及攻击的复现步骤或载荷，只聚焦于 防御的教训。

  • Krebs on Security「What We Can Learn from the Capital One Hack」(2019) — krebsonsecurity.com
  • ACM Transactions on Privacy and Security「A Systematic Analysis of the Capital One Data Breach」— dl.acm.org
  • CyberScoop「US financial regulator fines Capital One $80 million over data breach」(2020) — cyberscoop.com
  • Capital One 官方新闻稿（向 SEC 提交的 8-K, 2019） — sec.gov

接下来阅读

FAQ

QCapital One 事故的根本原因是什么？
A

并非单一原因，而是多层防御接连失守。起点是一个 SSRF 缺陷（能让服务器代为向任意目标发起请求）。攻击者借此抵达云端的元数据服务端点，而其后挂载的 IAM 角色又拥有过大权限，因此用临时密钥就能读出整个存储。只要其中任意一层正确闭合，损失就会被止住。

Q我自己的小型服务也会受影响吗？
A

会。SSRF 往往诞生于「接收一个 URL 并去拉取」「代为获取图片或 Webhook」这类司空见惯的功能。只要你跑在云上，从元数据服务端点窃取凭证这件事，不分规模都可能发生。本文的三项对策（IMDSv2、IAM 最小权限、出站目标白名单）对个人开发同样有效。

Q只要部署了 WAF（Web 应用防火墙）就能防住吗？
A

不能。在这起事故里，恰恰是充当 WAF 角色的组件本身被 SSRF 利用了。WAF 只能拦截某些类型的攻击，配置失误反而会成为弱点。「有 WAF 所以安全」是一种误解；还需要输入校验、最小权限和元数据保护。