Go HTTP 出站请求如何防 SSRF：URL 解析、内网地址拦截与重定向复核

有些 Go 服务会接收一个 URL，再替用户抓取网页、校验图片或读取远程配置。功能上线后，攻击者把参数换成 http://127.0.0.1:8080 只是最直观的测试；更麻烦的是域名解析、IPv4 映射 IPv6、十进制地址和 30x 跳转都能改变真正的出站目标。

可行的防护边界是：先解析并规范化 URL，只允许 http/https，解析出地址后拒绝回环、私网、链路本地和未指定地址；连接时仍使用同一套判断逻辑，重定向到新主机时再次校验。URL 字符串里没出现“localhost”，不代表请求就是安全的。

先把真正要保护的资产列出来

SSRF 的危害不只是一条内网 URL 被访问。Go 进程所在网络里的管理端口、云环境元数据地址、调试接口和带有内网凭据的服务，往往才是高价值目标。应用本身也可能因为读取了响应体，把内部错误信息或配置内容继续返回给外部调用方。

字符串校验为什么挡不住真实目标

strings.Contains(host, "localhost") 只能拦住一个拼写。主机名可能解析到私网地址，地址还可能用 IPv6 表示；而 url.Parse 解析出的 Host 也可能包含端口，不能直接拿整个字符串做网段判断。

第一步应该把协议、主机名和端口拆开，并拒绝没有主机名的 URL。下面的函数只负责解析，不负责联网，适合作为输入门禁。

package outbound

import (
    "fmt"
    "net"
    "net/url"
    "strings"
)

func parseTarget(raw string) (*url.URL, string, error) {
    u, err := url.ParseRequestURI(raw)
    if err != nil || u.User != nil {
        return nil, "", fmt.Errorf("invalid target")
    }
    if u.Scheme != "http" && u.Scheme != "https" {
        return nil, "", fmt.Errorf("scheme is not allowed")
    }
    host := strings.TrimSuffix(u.Hostname(), ".")
    if host == "" || net.ParseIP(host) != nil {
        return u, host, nil
    }
    return u, strings.ToLower(host), nil
}

这里拒绝了 URL 中的用户信息，避免把凭据悄悄带进出站请求；去掉末尾根域名点只是规范化操作，不能把它当成安全判断。域名仍要在真正拨号前解析。

用 netip 判断地址，并覆盖 IPv4 与 IPv6 边界

仅判断 IsPrivate 还不够。回环地址、链路本地地址和未指定地址需要明确拒绝；IPv4 映射 IPv6 也必须先还原成 IPv4 语义，否则 ::ffff:127.0.0.1 可能漏过只看 IPv4 的代码。

package outbound

import "net/netip"

func blockedAddr(addr netip.Addr) bool {
    if addr.Is4In6() {
        addr = addr.Unmap()
    }
    return !addr.IsValid() ||
        addr.IsLoopback() ||
        addr.IsPrivate() ||
        addr.IsLinkLocalUnicast() ||
        addr.IsUnspecified()
}

生产策略通常还会维护企业自己的拒绝网段，例如容器网桥、服务网格地址和云厂商元数据网段。它们不要散落在多个 handler 里，应该集中成可审计的策略函数，并为每个拒绝原因写表格驱动测试。

地址判断通过后，不能直接把解析结果丢给一个默认客户端就结束了。DNS 可能在解析和连接之间变化，所以拨号函数也要重新解析并检查候选地址。

把检查放到 DialContext，守住真正的连接出口

安全策略最怕只存在于业务层。业务层可以检查原始 URL，但真正建立 TCP 连接的是 Transport。把地址判断放进自定义 DialContext，至少能让每次拨号前再次确认 IP 不在拒绝范围。

package outbound

import (
    "context"
    "fmt"
    "net"
    "net/netip"
    "time"
)

func dialAllowed(ctx context.Context, network, address string) (net.Conn, error) {
    host, port, err := net.SplitHostPort(address)
    if err != nil {
        return nil, fmt.Errorf("bad address: %w", err)
    }
    ips, err := net.DefaultResolver.LookupNetIP(ctx, "ip", host)
    if err != nil {
        return nil, fmt.Errorf("resolve target: %w", err)
    }
    for _, ip := range ips {
        if blockedAddr(ip) {
            continue
        }
        d := net.Dialer{Timeout: 3 * time.Second}
        return d.DialContext(ctx, network, net.JoinHostPort(ip.String(), port))
    }
    return nil, fmt.Errorf("all resolved addresses are blocked")
}

示例把第一个可用地址作为最小实现，真实项目要根据 IPv4/IPv6 双栈策略处理失败后切换，并记录 DNS 结果。更重要的是，不要让 Transport 又通过一个未经审计的代理改变出口；代理策略应显式配置，不能把环境变量当成安全边界。

重定向每一跳都重新检查

公网 URL 返回 302，并不意味着后续仍在公网。CheckRedirect 收到新请求时，至少要重新检查协议、主机名和解析后的地址；跨主机跳转时还应清理原请求中的 Authorization 等敏感头。

client := &http.Client{
    Timeout: 5 * time.Second,
    CheckRedirect: func(next *http.Request, history []*http.Request) error {
        if len(history) >= 3 {
            return http.ErrUseLastResponse
        }
        if next.URL.Scheme != "http" && next.URL.Scheme != "https" {
            return fmt.Errorf("redirect scheme is not allowed")
        }
        if err := verifyResolvedHost(next.Context(), next.URL.Hostname()); err != nil {
            return err
        }
        next.Header.Del("Authorization")
        return nil
    },
}

resp, err := client.Get(target)
if err != nil {
    return err
}
defer resp.Body.Close()

这段代码里的 verifyResolvedHost 应复用同一地址策略，而不是再写一份“看起来差不多”的判断。重定向次数限制解决的是资源消耗，地址复核解决的是边界绕过，两者不能相互替代。

日志、响应体和超时也是安全控制

地址被拦截后只返回一个 500，排查时很难区分 DNS 失败、私网命中还是跳转次数过多。建议记录请求编号、原始主机名、解析结果、跳转次数、拒绝类别和耗时；不要记录带查询参数的完整 URL，里面可能有令牌。

响应体也要限长。一个看似安全的公网地址仍可能返回很大的内容，或者让连接长时间占用 worker。可以用 io.LimitReader 包住读取逻辑，并同时设置请求总超时、连接超时和响应头等待上限。安全边界和资源预算应该在同一份验收清单中出现。

上线前的验证清单

• 输入校验：只允许 http/https，拒绝用户信息、空主机和异常端口。
• 地址校验：覆盖回环、私网、链路本地、未指定、企业自定义网段及 IPv4 映射 IPv6。
• 拨号校验：DialContext 前重新解析，确认 Transport、代理和 DNS 行为可解释。
• 跳转校验：限制次数，每一跳重新检查，跨主机时清理敏感请求头。
• 资源校验：总超时、响应头超时、响应体上限和日志脱敏都有测试。

测试不只写一个 127.0.0.1。至少把 10.0.0.8、192.168.1.10、169.254.169.254、::1 和 ::ffff:127.0.0.1 放进表格；再用一个测试服务器模拟公网入口跳转到拒绝目标，确认请求在第二跳停止。

相关问题

只禁用 localhost 是否足够？

不够。攻击者可以直接使用 IP、其他回环写法、私网地址、链路本地地址或解析到内网的域名。应以解析后的地址和拨号出口为判断对象。

为什么不能只在 handler 里检查一次？

DNS 结果和重定向目标可能变化，真正连接由 Transport 完成。业务层检查负责快速拒绝，DialContext 和 CheckRedirect 负责守住后续边界。

禁止所有重定向是不是最简单？

如果业务不需要跳转，直接禁止最省心；如果必须跟随，就限制次数、逐跳复核地址，并在跨主机时清理敏感头。

IsPrivate 能代替全部网段规则吗？

不能。它不能表达你的企业自定义网段、云元数据策略和代理出口约束。把标准判断与业务拒绝网段合并成一份可测试策略更稳妥。

把出站请求当成一个受控能力

SSRF 防护不是给 URL 加几条黑名单，而是把“解析、解析结果、拨号、重定向、响应读取和审计”串成一条受控链路。入口检查让错误尽早失败，Transport 复核避免 DNS 变化绕过，重定向检查守住后续主机，超时和响应体上限则限制攻击成本。

当这几个点都有单测和日志证据后，新增一个远程抓取功能才有清晰的评审边界：允许访问哪些网段、是否允许跳转、代理从哪里来、失败如何告警，都能在代码和验收表里找到答案。