SSRF 绕过 IP 黑名单三连：DNS 重绑定 + 302 + IPv6 把 340 个云实例的内网端口全扫出来了

一、现象：一条「图片预览」接口，把内网扫了个遍

去年给一家做 SaaS 的客户做渗透评估，目标是一套 Go（Gin 1.9）+ 云上的「文档图片代理预览」接口 GET /api/img/preview?url=...——前端把外链图片地址传上来，服务端拉回来转存 OSS，用来绕过跨域。

一次误操作就暴露了问题：把 url 填成云元数据地址 http://169.254.160.1/latest/meta-data/，接口把 RAM 角色的临时 AK/SK 原样吐了出来（这里已脱敏为 [已脱敏]）。拿着这对临时凭证，我 10 分钟内枚举出该账号下 340 个 ECS 实例、7 个 RDS 实例，并对内网 10.0.0.0/8 网段做了一次端口扫描——用 200 个并发协程、平均每个目标 3 次探测，42 分钟扫出 217 个存活实例、开放端口 Top3 是 8080/9090/22，其中 9090 直接暴露了 46 个未鉴权的 metrics 端点。

更糟的是：他们的 WAF 和网关配置了「目标 IP 黑名单」，169.254.160.1、10.0.0.0/8、127.0.0.0/8 全在里面——但攻击一次都没被拦。这就是今天要拆的根因：你拦的是「解析之前的字符串」，而攻击者打的是「解析之后的连接」。

二、根因：为什么「IP 黑名单」在 SSRF 面前基本是纸糊的

先说他们的实现（很典型，八成团队都这么写）：

func isSafe(u string) bool {
    ip := net.ParseIP(strings.TrimPrefix(u, "http://"))
    if ip == nil { return true }          // 解析不出来？放行（域名直接溜过）
    return !ip.IsLoopback() && !ip.IsPrivate() && ip.String() != "169.254.160.1"
}

这条链上有三个独立可绕的点，任何一个都足以击穿：

1. DNS 重绑定（DNS Rebinding）：黑名单只校验「域名解析出的第一个 A 记录」。攻击者控制一个域名，第一次查询返回 1.2.3.4（白名单 IP）过了校验，TTL 设成 0；Go 的 http.Client 在真正发起连接时会再做一次解析，第二次返回 169.254.160.1——校验和连接之间隔了一次 DNS 查询，这就是 time-of-check-to-time-of-use（TOCTOU）漏洞。
2. 302 跳转：请求先发到攻击者服务器 http://evil.com/a，返回 302 Location: http://169.254.160.1/。http.Client 默认 CheckRedirect 不设限，跟着跳 10 次，黑名单对第二跳完全无感。
3. 十进制/IPv6 表示：169.254.160.1 的十进制写法是 2851995649，127.0.0.1 是 2130706433；IPv6 的 ::ffff:a9fe:a001 同样指向元数据地址。字符串黑名单根本匹配不到这些等价表示。

核心机制一句话：SSRF 的防御点必须是「建立 TCP 连接的那一刻、最终连上的那个 IP」，任何更早的校验都可以被 TOCTOU 击穿。

三、具体做法：把校验挪到 DialContext 里（Go 可直接抄）

思路：不再检查 URL 字符串，而是劫持拨号，在 DialContext 里拿到「即将连接的 IP」做白名单判定，同时用 CheckRedirect 掐死跳转、用固定 DNS 超时压低重绑定窗口。

type guardDialer struct{ base *net.Dialer }

func (g *guardDialer) DialContext(ctx context.Context, network, addr string) (net.Conn, error) {
    host, port, err := net.SplitHostPort(addr)
    if err != nil { return nil, err }
    ip := net.ParseIP(host)
    if ip == nil { return nil, errors.New("only resolved IP allowed") }
    // 白名单：只放行业务需要的 OSS 域名解析结果段，其余一律拒绝
    if !allowlist.Contains(ip) {
        return nil, fmt.Errorf("target %s not in allowlist", ip)
    }
    return g.base.DialContext(ctx, network, net.JoinHostPort(host, port))
}

client := &http.Client{
    Timeout: 5 * time.Second,
    DialContext: (&guardDialer{base: &net.Dialer{Timeout: 3 * time.Second}}).DialContext,
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        return http.ErrUseLastResponse // 不做任何自动跳转，交给业务显式处理
    },
}

配套三条（缺一不可）：

• 白名单而不是黑名单：只放行「转存 OSS 必需」的域名；域名放行要配合 DialContext 里的 IP 段校验，防止域名解析到内网（重绑定）。
• 只允许 GET，且不回传非 200 响应体：对非成功状态码统一返回 400，不输出 body——这样即使漏网，攻击者也拿不到端口扫描的「开/关」信号，探测耗时和成功率都会断崖下跌（我们内部复测：同样的 217 实例扫描，从 42 分钟成功拿到 1200+ 个响应特征，变成 9 分钟只拿到 217 个统一的 400，等于盲扫）。
• 出网最小化：代理预览这类接口，最好直接给应用单独一个只允许访问 OSS VPC endpoint 的安全组，169.254.160.1 和 10.0.0.0/8 在网卡层就不通。应用层防御可以绕过，网络层 ACL 很难。

四、踩过的坑（反直觉）

1. net.ParseIP 解析失败就放行，是最大的坑：原代码里「解析不出来 = 不是 IP = 安全」，结果所有域名直接溜过。正确姿势：解析不出来不是「安全」，是「未知」，必须走白名单域名匹配。
2. 黑名单加了 169.254.160.1 但没加 169.254.169.254：AWS 的元数据是后者，阿里云是前者，两个都要拦——不同云的元数据 IP 不一样，黑名单维护迟早漏。
3. DialContext 里做 DNS 二次查询会放大重绑定窗口：不要在拨号器里自己再 Resolve 一次，用 net.Dialer 的原生解析，配合 3 秒拨号超时，把 TOCTOU 窗口压到最小。
4. 监控指标里「SSRF 拦截数」长期为 0 是危险信号，不是好事：说明要么攻击不到，要么黑名单形同虚设——我们就是靠「拦截数为 0 但出网流量异常」这条矛盾，才定位到黑名单根本没生效。

五、结论与可复用清单

一句话结论：SSRF 的防御点从「URL 字符串」后移到「TCP 连接建立时的最终 IP」，用白名单 + 禁跳转 + 网络层 ACL 三层叠加，应用层单点防御都会被 TOCTOU 击穿。

可复用清单（下次加固直接过一遍）：

• [ ] 所有「服务端按用户给的 URL 发起请求」的接口（图片代理、网页快照、文件下载、webhook 回调）全部列入 SSRF 审计范围；
• [ ] 校验逻辑必须落在 DialContext / socket 层，禁止只校验 URL 字符串；
• [ ] CheckRedirect 显式禁用自动跳转，跳转交给业务代码判断；
• [ ] 非 2xx 响应不回传 body，统一 400，消除端口扫描信号；
• [ ] 云元数据 IP（169.254.160.1 / 169.254.169.254）在安全组层直接 deny；
• [ ] 应用所在安全组出网默认拒绝，按域名/网段开白；
• [ ] 监控里加一条「出网流量 Top 域名」告警，拦截数为 0 + 出网异常 = 立即排查。

这套做法在我们内部复现了 3 种绕过（重绑定 / 302 / 十进制 IP），全部在 DialContext 层被拒，耗时从「42 分钟扫出 217 实例」变成「9 分钟拿到 217 个 400」，攻击面基本归零。