flawopen.com/安全事件/Capital One SSRF

Capital One:一处被低估的 SSRF 漏洞,如何将普通 Web 请求变成云端主权限

Critical — 100M+ records CWE-918: Server-Side Request Forgery Disclosed July 2019
通俗解释 (ELI5)

银行有一位专门替客户去指定地点取回信件的跑腿员。而在银行内部走廊尽头,有一间没有挂牌的内勤室,只要有人敲门就向其发放整栋大厦的总钥匙。一位心怀不轨的访客吩咐跑腿员去走廊尽头敲门取件,跑腿员照办,并把整栋大厦的万能钥匙原封不动交给了访客。

Why this incident reshaped cloud defaults

Capital One is the reason SSRF stopped being treated as a second-tier bug class. Before it, SSRF was often triaged as an information-disclosure nuisance. After it, the industry understood that in a cloud environment SSRF is a credential-theft primitive — because the cloud platform itself puts a credential vending machine at a fixed, well-known, unauthenticated address inside every instance.

AWS introduced IMDSv2 in November 2019, requiring a PUT to obtain a session token and defaulting to a low IP hop limit. Both changes specifically break the "one blind GET" pattern this attack relied on. Equivalent hardening exists across other cloud providers.

The lessons that actually transfer

FAQ

Does IMDSv2 make SSRF safe?

No — it removes one very high-value target. SSRF can still reach internal admin interfaces, databases, Kubernetes APIs, and other services that trust the network position of the caller. It remains a serious bug class on its own merits.

Would a WAF have stopped this?

The vulnerable component in this case was a web application firewall, which is a useful reminder that security appliances are applications too. Filtering rules can raise the cost of exploitation but do not address the underlying design, which is that a server will fetch whatever address it is told to.

Related reading

参考资料与权威通告