服务端请求伪造（SSRF）

为什么云环境让 SSRF 变成高危

SSRF 并非新漏洞，但 AWS、GCP、Azure 的元数据服务让它的危害等级直线上升。AWS EC2 实例可通过 http://169.254.169.254/latest/meta-data/ 获取实例的 IAM 临时凭证，无需认证。攻击者若能控制服务器的 HTTP 请求目标，就能读取这个地址，进而取得云账户权限，横向移动到整个基础设施。

2019 年 Capital One 数据泄露事件（1亿条用户记录）的根因正是 SSRF 加上 WAF 配置不当：攻击者通过一个开放的 WAF 代理实例触发 SSRF，读取了 EC2 元数据中的 IAM 凭证，再用凭证访问 S3 存储桶。

内网探测是另一个典型场景：通过改变请求地址为 http://192.168.1.1、http://10.0.0.1:8080 等，可探测内网拓扑、攻击未对外暴露的 Elasticsearch、Redis、内部管理后台。[1]

防御策略

分层防御是正道。第一层：服务端白名单，只允许请求预定义的合法域名，拒绝一切 IP 直接访问。第二层：DNS 重绑定防护——解析域名后、发起请求前再次检查解析结果是否指向内网地址（因为攻击者可控 DNS 先返回合法 IP 通过白名单，随即切换到内网 IP）。第三层：给发起对外 HTTP 请求的服务隔离网络命名空间，使其物理上无法访问 169.254.x.x 或内网段。

AWS 在 2019 年 Capital One 事件后于同年推出了 IMDSv2（实例元数据服务 v2），要求在访问元数据前先发起一个 PUT 请求获取会话令牌，SSRF 无法完成这个预检步骤，从根源上封堵了元数据窃取路径。