当服务器替你发请求：SSRF 如何把内网暴露给攻击者
你访问了一个网站，网站帮你去取一张图片——这听起来再正常不过了。但问题就出在这个"帮你去取"上。如果服务器在拿到你给的 URL 之后，不验证、不过滤，直接去请求，那它就不只是在帮你取图片，它在帮你取整个内网。
这就是 SSRF，Server-Side Request Forgery。攻击者精心构造一个 URL，让服务器去访问它本来不该访问的内网资源——云环境的元数据接口、内部服务的 API、数据库的管理端口。服务器有权限访问这些东西，而攻击者没有，但攻击者借服务器的手去碰了它们。2019 年 Capital One 数据泄露，超过一亿条客户记录被盗，入口就是一个 SSRF 漏洞，攻击者通过它拿到了云实例的 IAM 凭证。
SSRF 的杀伤力跟部署环境直接相关。传统机房里，它可能只泄露内网信息。但到了云环境就不一样了——AWS、GCP、Azure 都在
防御的思路其实很直：服务器不该请求的地方，就不让它请求。最有效的措施是维护一个允许的目标白名单，非白名单内的请求直接拒绝。如果白名单不好维护，至少做到禁止请求私有 IP 段和云元数据地址。另外，在出口方向部署防火墙策略，限制服务器出站能访问的端口和协议，也能大幅缩小爆破面。如果你用云服务，很多提供商已经支持 IMDSv2，要求请求必须带一个一次性 token 才能访问元数据——这就把 SSRF 获取凭证这条路基本堵死了。
#Security
你访问了一个网站，网站帮你去取一张图片——这听起来再正常不过了。但问题就出在这个"帮你去取"上。如果服务器在拿到你给的 URL 之后，不验证、不过滤，直接去请求，那它就不只是在帮你取图片，它在帮你取整个内网。
这就是 SSRF，Server-Side Request Forgery。攻击者精心构造一个 URL，让服务器去访问它本来不该访问的内网资源——云环境的元数据接口、内部服务的 API、数据库的管理端口。服务器有权限访问这些东西，而攻击者没有，但攻击者借服务器的手去碰了它们。2019 年 Capital One 数据泄露，超过一亿条客户记录被盗，入口就是一个 SSRF 漏洞，攻击者通过它拿到了云实例的 IAM 凭证。
SSRF 的杀伤力跟部署环境直接相关。传统机房里，它可能只泄露内网信息。但到了云环境就不一样了——AWS、GCP、Azure 都在
169.254.169.254 暴露实例元数据，一旦 SSRF 触达这个地址，临时凭证、角色权限全出来了，直接接管云资源。所以云时代 SSRF 的危害被放大了不止一个量级。防御的思路其实很直：服务器不该请求的地方，就不让它请求。最有效的措施是维护一个允许的目标白名单，非白名单内的请求直接拒绝。如果白名单不好维护，至少做到禁止请求私有 IP 段和云元数据地址。另外，在出口方向部署防火墙策略，限制服务器出站能访问的端口和协议，也能大幅缩小爆破面。如果你用云服务，很多提供商已经支持 IMDSv2，要求请求必须带一个一次性 token 才能访问元数据——这就把 SSRF 获取凭证这条路基本堵死了。
#Security
