SSRF：让服务器替你发请求

SSRF 有个很别扭的地方：漏洞本身不是”读到了什么”，而是”服务器替你做了一件事”。

你给一个 URL，服务器去请求它。这个行为本身完全正常——所有图片代理、链接预览、webhook 回调、在线翻译都在干这事。出问题的是：它没有限制这个 URL 能指向哪里。

于是你可以让它去请求 127.0.0.1，去请求内网的管理后台，去请求云厂商的元数据接口。它站在内网里，用它自己的身份，做你从外面做不到的事。

三个前提，缺一不可

判断一个功能有没有 SSRF，看三件事：

一、参数是完整的 URL 还是只有域名。完整 URL 可控，就能改协议、改端口、改路径。只让填域名的话，攻击面小很多。

二、返回内容会不会回显给你。能回显的是”完整型”，最容易利用，直接读数据。不回显的是”盲打型”，只能靠外带通道确认。

三、有没有出网能力。服务器在内网且禁止出网，很多玩法就没了。但只要它能访问自己的内网，SSRF 的价值依然存在。

第三条最容易被忽略。很多人以为”我们的服务器不能上外网，所以 SSRF 无所谓”——恰恰相反，能访问内网才是 SSRF 最危险的地方。

盲打型：先解决”有没有”

大部分 SSRF 不回显。页面只会显示”图片加载失败”或者一直转圈。

这时候需要的是一条带外通道：让服务器去访问一个你能看到日志的域名。

http://abc123.oob.example.com/

如果 DNS 查询记录里出现了这条，就证明了 SSRF 存在。Burp 的 Collaborator、interactsh 都是干这个的，本质上就是给你一个能记录 DNS 和 HTTP 请求的域名。

确认存在之后再看能走多远。DNS 通了说明能解析外部域名，HTTP 通了说明能发完整请求。这两者差别很大：某些环境只允许 DNS，HTTP 被防火墙拦了。

内网里到底有什么

值得一试的目标，按价值排：

云厂商元数据。这是 SSRF 的”头奖”。阿里云是 100.100.100.200，AWS 是 169.254.169.254，GCP 也有自己的地址。拿到实例角色的临时凭证，等于拿到了这台机器在云上的身份。

Redis / Memcached。内网里通常不设密码，通过 gopher:// 协议可以构造任意 TCP 数据，往 Redis 里写文件、写计划任务。这条链子是老牌组合。

内网管理后台。很多后台只监听内网，从外面访问不到，但从服务器自己访问就是 127.0.0.1:8080 一条请求的事。

内网 API。微服务之间经常假设”内网就是可信的”，接口不做鉴权。SSRF 让你借用这个信任。

绕过：为什么”过滤 127.0.0.1″没用

这是黑名单防御永远的困境。IP 地址的写法太多了：

最后两条最要命，因为它们绕过的不是”写法”，而是”校验时机”。

第一条是 DNS：你注册一个域名，A 记录指向 127.0.0.1，服务端只看字符串就放行了。

第二条是跳转：你提供一个自己控制的域名，返回 302 跳到内网地址。如果服务端只校验了初始 URL，跟着跳转走就进去了。

还有一个更隐蔽的：DNS 重绑定。域名第一次解析返回公网 IP（通过校验），第二次返回内网 IP（实际请求）。利用的是”校验”和”请求”之间的时间差。防御方要防这个，必须在解析之后校验 IP，并且用同一个解析结果去连接。

云元数据这几年变了

值得单独说，因为这是 SSRF 价值变化的分水岭。

早期的元数据接口没有任何防护，一个 GET 就能拿到临时凭证。后来 AWS 推出了 IMDSv2：先用 PUT 请求拿一个 token，再带着 token 访问元数据。

这一招很有效，原因在于：SSRF 通常只能发 GET，而且带不了自定义请求头。拿不到 token，就读不到元数据。

所以现在测 SSRF，第一步应该是判断目标用的是 IMDSv1 还是 v2。如果 v2 强制开启，元数据这条链基本断了，得转而看内网其他服务。

国内的情况类似：阿里云元数据接口对请求头有要求，直接 GET 不一定能拿到东西。这也是为什么很多”SSRF 挖到元数据”的教程现在跑不通——写教程的时候还没这些限制。

防御：黑名单是徒劳的

列一堆”禁止访问 127.0.0.1、10.0.0.0/8″的规则，永远堵不完。正确的做法是反过来：

一、白名单。如果业务只需要访问固定的几个域名，就只允许这几个。这是唯一彻底的办法。

二、解析后再校验 IP。先把域名解析成 IP，判断这个 IP 是否在允许范围，然后用这个 IP 去连接（不要再解析一次）。这样能防住 DNS 重绑定。

三、禁止跳转。或者跳转后重新走一遍完整校验。很多实现只校验第一次请求。

四、限制协议。只允许 http/https。禁掉 file://、gopher://、dict://，能挡掉一大半内网利用链。

五、出网防火墙。服务器本身只允许访问必要的外网地址。这条是兜底，也是最有效的——就算代码有洞，出不去也没用。

第五条经常被跳过。我见过太多”代码层面做了严格校验”的系统，实际上一台机器能访问整个内网，一个没覆盖到的入口就全盘皆输。

最后

SSRF 是那种”看起来不起眼，实际影响巨大”的漏洞。它不直接给你数据，它给你一个位置——内网里的位置。

从这个位置能做什么，取决于内网有多”信任”自己。而大多数内网，信任得过分。

所以如果你在加固系统，别只盯着输入校验。问问自己：这台服务器被打穿之后，攻击者能到哪？这个问题的答案，比任何过滤规则都重要。

本文仅讨论自有系统与书面授权范围内的安全测试。对未授权目标进行 SSRF 探测属于违法行为。