当你的服务器替攻击者访问了内网

你写了一个在线预览功能，用户填入URL，服务端帮你抓取网页内容返回——听起来很实用对吧？但问题在于，这个URL的请求是从你的服务器发出的，而你的服务器能看到的东西和用户能看到的东西完全不同。这就是SSRF（Server-Side Request Forgery）的核心：攻击者借你的服务器之手，访问本来碰不到的内网资源。

最经典的利用场景是云环境的元数据接口。AWS的 http://169.254.169.254/latest/meta-data/ 可以直接拿到IAM临时凭证，GCP和Azure也有类似的端点。2019年Capital One数据泄露，攻击者就是通过SSRF读取了EC2元数据，拿到IAM角色凭证后访问了S3存储桶，1.06亿条记录就这么被拖走了。

SSRF的绕过手法相当丰富。http://127.0.0.1 被拦？试试 http://0177.0.0.1、http://0x7f000001，或者 http://[::1]。域名指向黑名单IP也被拦？DNS Rebinding登场—— 第一次解析返回合法IP，第二次解析返回127.0.0.1。甚至可以通过302跳转让你的服务器自己在重定向阶段跳进内网，而初始URL完全合法。

防御上，最硬的方案是在网络层直接禁止服务器向内网发起请求，egress防火墙规则比应用层校验可靠得多。如果必须在应用层做，URL解析后要真正做IP校验，而且要防止TOCTOU——先解析域名拿到IP、校验通过后再发请求的窗口期里，DNS可能已经变了（这又回到了DNS Rebinding）。所以最靠谱的模式是：解析→校验IP→用这个IP直连，跳过DNS重新解析。



#Security