你的服务器正在替攻击者发请求——认识 SSRF
假设你做了一个功能，用户提交一个 URL，服务器帮忙去抓取那张图片再返回缩略图。看上去很合理，对吧？但问题出在这里：服务器发出的请求，用的是内网身份。攻击者提交的 URL 如果指向云元数据接口
SSRF 的危害远不止泄露云凭证。内网服务之间往往互相信任、不做鉴权，攻击者可以通过你的服务器IP访问到本不该暴露的 Redis、Elasticsearch、甚至 Kubernetes API。2021 年的 Capital One 泄露 1 亿用户数据，根因就是 SSRF 读取了 EC2 元数据后拿到临时凭证，进而访问 S3 存储桶。
防御 SSRF 的思路有三层。最外层是限制目标地址：域名解析后检查 IP 是否落在内网段，但这里有个老陷阱——DNS Rebinding 可以让首次解析返回公网 IP、二次解析返回内网 IP，绕过你的校验。中间层是网络隔离：让处理用户请求的应用容器完全无法访问云元数据接口和内网管理端口，从拓扑上切断可能性。最内层是取消凭据传递：使用 IMDSv2 要求
真正安全的系统不是"我检查了你给我的地址"，而是"就算你骗过了检查，你也拿不到东西"。
#Security
假设你做了一个功能，用户提交一个 URL，服务器帮忙去抓取那张图片再返回缩略图。看上去很合理，对吧？但问题出在这里：服务器发出的请求，用的是内网身份。攻击者提交的 URL 如果指向云元数据接口
http://169.254.169.254/latest/meta-data/，你的服务器就会乖乖地把 AWS 的 Access Key 全部拉回来交给对方。这就是 SSRF——Server-Side Request Forgery，让服务器变成攻击者的代理。SSRF 的危害远不止泄露云凭证。内网服务之间往往互相信任、不做鉴权，攻击者可以通过你的服务器IP访问到本不该暴露的 Redis、Elasticsearch、甚至 Kubernetes API。2021 年的 Capital One 泄露 1 亿用户数据，根因就是 SSRF 读取了 EC2 元数据后拿到临时凭证，进而访问 S3 存储桶。
防御 SSRF 的思路有三层。最外层是限制目标地址：域名解析后检查 IP 是否落在内网段，但这里有个老陷阱——DNS Rebinding 可以让首次解析返回公网 IP、二次解析返回内网 IP，绕过你的校验。中间层是网络隔离：让处理用户请求的应用容器完全无法访问云元数据接口和内网管理端口，从拓扑上切断可能性。最内层是取消凭据传递：使用 IMDSv2 要求
PUT 请求先拿 token 才能访问元数据，IP 层面的 SSRF 根本无法完成这个交互。真正安全的系统不是"我检查了你给我的地址"，而是"就算你骗过了检查，你也拿不到东西"。
#Security
