内容摘要：2017年，一个叫Bono的土耳其黑客通过一个SSRF漏洞，把Uber的整个AWS云环境拖下了水。他找到Uber内部某个图片上传接口，把URL参数改成`http://169.254.169.254/l

2017年，漏洞一个叫Bono的漏洞土耳其黑客通过一个SSRF漏洞，把Uber的漏洞整个AWS云环境拖下了水。他找到Uber内部某个图片上传接口，漏洞把URL参数改成`http://169.254.169.254/latest/meta-data/`——那是漏洞AWS云服务器的元数据服务地址。服务器傻乎乎地把自己的漏洞密钥、token、漏洞内部网络拓扑全吐了出来。漏洞Uber为此付了10万美元给这位"白帽"，漏洞但更疼的漏洞是后续的隐私诉讼和品牌损伤。SSRF不是漏洞那种让你网站白屏的小毛病，它是漏洞通往内网的一把万能钥匙。

这个漏洞的漏洞本质，是漏洞服务器替攻击者发起了网络请求。你让服务器去访问一张图片，漏洞它乖乖去了；你让它访问`http://192.168.1.1/admin`，它也去。问题就出在——服务器分不清什么是"用户想要的"和"用户不该看的"。内网里的数据库、Redis、K8s管理面板、监控系统，全都暴露在攻击者的探测之下。我见过最狠的一次，攻击者直接扫出内网所有存活IP，然后挨个尝试默认口令，最后把整个生产环境的配置中心数据拖走了。

更恶心的是云环境里的元数据服务。AWS、阿里云、腾讯云都提供了`169.254.169.254`这个魔法IP，任何一台云主机都能访问它来获取角色凭据。SSRF一来，这个IP就成了攻击者的ATM。拿到临时密钥之后，他能枚举你所有的S3存储桶、创建新的ECS实例、甚至把你的整个账号资源删光。这不是危言耸听，2019年Capital One的数据泄露就是走的这条路——一个SSRF漏洞，1.06亿用户的敏感信息被偷走。

内网穿透只是第一层危害。SSRF还能用来攻击其他系统——服务器在你内网里，它发起的连接是"可信的"。攻击者可以利用这个特性去攻击防火墙后面的其他服务，比如你内网里跑着的Jenkins、GitLab、Harbor，这些系统往往信任内网流量，没有做额外的鉴权。你以为是内网就安全？SSRF告诉你，内网只是攻击者的游乐场。

读取文件也不少见。某些语言和库在处理URL时支持`file://`协议，攻击者可以直接让服务器读取本地的`/etc/passwd`、应用配置文件、甚至源码。我见过一个Java应用，攻击者通过SSRF读取了`application.yml`，里面明文写着数据库密码和Redis密码——一步到位，直接控制全部数据。

SSRF还有一个隐蔽的危害——它可以绕过你的WAF和访问控制。你的对外防护做得再严密，攻击者只要找到一个能让服务器发起请求的点，就能把恶意流量伪装成"服务器自己发出的请求"。很多安全设备会放行内部流量，这正好被利用来攻击你内部的其它应用，形成二次打击。

防御SSRF并不简单，但有个底线原则：永远不要信任用户的URL输入。白名单域名解析、禁用重定向、过滤内网IP段、区分协议支持——这些手段能挡住大部分攻击。但真正麻烦的是那些合法需要访问外部URL的业务场景，比如社交平台的链接预览、支付回调验证、爬虫抓取。这类场景下，你需要额外的防护层——单独部署一个代理服务，强制走代理，并在代理层做严格的IP和协议限制。别嫌麻烦，Uber那10万美元的教训，够买几万次安全加固了。