Go 重定向请求中的 Authorization 继承策略

Go 的 http.Client 会自动跟随 301、302、303、307 和 308 重定向。初始请求里的普通请求头会被复制到后续请求，但 Authorization、Cookie 等敏感头只会向初始主机或它的子域继续继承；跳到无关域名时，Go 会剥离这些头。生产代码还应通过 CheckRedirect 明确限制允许的目标，尤其要阻止 HTTPS 降级和未经登记的跨主机跳转。

官方文档：https://pkg.go.dev/net/http

先界定 Authorization 要保护的资产

Authorization 通常代表访问令牌、Basic 凭据或签名材料。重定向的风险不只在于“是否带头”，还在于服务端返回的 Location 是否仍属于可信边界。Go 当前实现会从初始请求复制请求头；当目标主机不是初始主机时，会判断目标是不是初始域名的精确匹配或子域。像 api.example.com 跳到 login.example.com 属于同一域边界，跳到 example.net 则不会继续发送敏感头。

攻击路径：Location 决定凭据会走到哪里

如果客户端把一个带令牌的请求交给不受控的入口，而入口可以返回任意 Location，重定向链就成了凭据的路由器。即使 Go 在跨域时剥离了 Authorization，后续代码若在 CheckRedirect 中无条件执行 req.Header.Set，仍然会把密钥主动送给攻击者控制的目标。

因此策略应先回答三个问题：目标主机是否在允许列表；目标协议是否仍然安全；这条链是否超过业务需要的跳转次数。判断通过后，再决定是否让客户端继续，而不是先补头再判断。

用 CheckRedirect 收紧目标和协议边界

下面的策略把原始 URL 固定为可信入口，只允许同主机或明确登记的 API 主机继续跳转，并拒绝 HTTPS 降级。日志只记录主机、协议和次数，不记录令牌本身。

package main

import (
    "errors"
    "fmt"
    "log"
    "net/http"
)

var errRedirectPolicy = errors.New("redirect target is not allowed")

func redirectPolicy(allowedHosts map[string]struct{}) func(*http.Request, []*http.Request) error {
    return func(req *http.Request, via []*http.Request) error {
        // 第一跳的请求保存在 via[0]，它是鉴权资产的原始信任边界。
        if len(via) == 0 {
            return nil
        }
        origin := via[0].URL
        target := req.URL

        // 不允许从 HTTPS 降级到 HTTP，避免令牌进入明文链路。
        if origin.Scheme == "https" && target.Scheme != "https" {
            log.Printf("redirect rejected: scheme=%s host=%s", target.Scheme, target.Host)
            return errRedirectPolicy
        }
        // 目标主机必须显式登记；不要因为它看起来像子域就自动信任。
        if _, ok := allowedHosts[target.Host]; !ok {
            log.Printf("redirect rejected: from=%s to=%s hops=%d", origin.Host, target.Host, len(via))
            return errRedirectPolicy
        }
        // 限制链长度，防止服务端配置错误让请求在多个入口间循环。
        if len(via) >= 5 {
            return fmt.Errorf("%w: too many hops", errRedirectPolicy)
        }
        return nil
    }
}

func newClient() *http.Client {
    // 允许列表使用完整 host，避免只比较字符串后缀造成边界误判。
    allowed := map[string]struct{}{
        "api.example.com": {},
        "auth.example.com": {},
    }
    return &http.Client{CheckRedirect: redirectPolicy(allowed)}
}

这里的允许列表比 strings.HasSuffix 更容易审计：evil-example.com 不会因为字符串结尾相似而被误判为可信域。示例保留了 http.Client 的默认头复制机制，但把业务真正关心的目标边界前置到回调中。

只在可信目标恢复 Authorization

有些系统会让登录入口先跳到 API 入口，并要求应用在可信跳转上重新设置令牌。这时应把“是否恢复”写成白名单策略，并从初始请求保存令牌，而不是从不可信的中间请求读取。更稳妥的做法是只恢复短期、作用域受限的凭据。

func newAuthenticatedClient(token string) *http.Client {
    allowed := map[string]struct{}{
        "api.example.com":  {},
        "auth.example.com": {},
    }

    client := &http.Client{}
    client.CheckRedirect = func(req *http.Request, via []*http.Request) error {
        // 没有跳转链时无需做额外处理；首个请求已经带上令牌。
        if len(via) == 0 {
            return nil
        }
        if _, ok := allowed[req.URL.Host]; !ok || req.URL.Scheme != "https" {
            // 拒绝未知主机或降级协议，避免凭据扩散到不可信目标。
            return errRedirectPolicy
        }
        // 只对明确允许的 HTTPS 目标恢复 Authorization。
        req.Header.Set("Authorization", "Bearer "+token)
        return nil
    }
    return client
}

这段代码的关键不是“手动 Set 一次”，而是先完成主机和协议判断。若允许列表来自配置中心，还要在配置加载处做格式校验，并把变更写入审计日志；不要让用户输入直接变成允许主机集合。

用 ErrUseLastResponse 保留可审计结果

如果业务不想把策略拒绝包装成请求错误，也可以在回调中返回 http.ErrUseLastResponse，让调用方拿到触发跳转的原始响应。不过只要回调返回普通错误，Client.Do 会返回一个包装后的 *url.Error，而此前响应体已经关闭。选择哪种方式取决于上层是否需要读取 3xx 响应内容。

func stopAtUntrustedRedirect(req *http.Request, via []*http.Request) error {
    if len(via) == 0 {
        return nil
    }
    // 业务只允许同主机跳转，跨主机时保留上一份响应供调用方判断。
    if req.URL.Host != via[0].URL.Host {
        return http.ErrUseLastResponse
    }
    return nil
}

调用方仍应关闭成功返回的 resp.Body。如果返回错误，重定向失败时可能同时得到一个非空响应，但该响应体已被客户端关闭，不能再次读取。

发布前的验证清单

• 允许主机按完整主机名匹配，而不是用模糊后缀判断。
• HTTPS 入口不会跟随到 HTTP；跨主机跳转默认拒绝。
• 日志只记录目标主机、协议、跳转次数和策略结果，不记录 Authorization 值。
• 需要恢复凭据时，恢复动作位于白名单判断之后，并使用作用域尽可能小的令牌。
• 成功响应关闭 Body；策略错误不重复发送同一个带凭据的请求。

常见问题

Go 会把 Authorization 发给任意重定向目标吗？

不会。默认逻辑只向初始主机或其子域继续复制敏感头；无关域名会被剥离。但这不是业务白名单，生产代码仍应显式拒绝不可信目标。

为什么同主机从 HTTPS 跳到 HTTP 仍要单独拦截？

因为 Go 的敏感头继承判断主要看主机边界，同主机的协议变化不会自动等价于跨域。协议降级会让凭据进入明文链路，所以需要在 CheckRedirect 中拒绝。

能不能在 CheckRedirect 里无条件重新设置 Authorization？

不建议。回调必须先校验目标主机、协议和跳转次数；无条件恢复会抵消客户端对跨域敏感头的保护。

处理 Go 重定向鉴权问题时，可以把原则压缩成一句话：先判断 Location 是否仍在可信边界，再决定是否继续请求和是否携带凭据，最后用脱敏日志留下可复盘的策略结果。