net/http: Authorization header stripping in client on redirects incorrect when redirecting from http to https

[h3kker]

What version of Go are you using (go version)?

$ go version
go version go1.12.4 darwin/amd64

Does this issue reproduce with the latest release?

Should (source code at https://golang.org/src/net/http/client.go indicates that)

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/heinz.ekker/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/heinz.ekker/coden/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.4/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dh/6nzg_lhs19l_kxwv21s_8wz80000gn/T/go-build031339938=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

A go cli application (singularity, https://github.com/sylabs/singularity) tries to make a http request with a Authorization: Bearer .. header.

What did you expect to see?

The request on the server with a Authorization: Bearer ... header

What did you see instead?

Header was stripped from the request. Trying to do the same request with the same headers with curl leaves the header intact.

I think the problem in this case is that

• the request goes out to http://singularity.example.com/v1/token-status
• the (proxy) redirects to https://singularity.example.com/v1/token-status
• shouldCopyHeaderOnRedirect strips the header before sending the redirected request

As far as I can see there is a problem in isDomainOrSubdomain. It does an equality or suffix match on the original + redirected hostnames. But the hostnames come from canonicalAddr, which appends the port from the protocol. So it would check whether singularity.example.com:80 is a suffix of singularity.example.com:443, which it isn't, and then strip the header.

It seems a bit strange, in this case it would kick in a security check for something that actually improves security ;-) It is either a bug in the code or in the documentation, which does not mention protocol or ports.

[dmitshur]

Thanks for the report.

/cc @bradfitz

[neild]

From my reading, libcurl's behavior is to keep sensitive headers only when the hostname is an exact match (ignoring the port).

I think that if we're going to preserve a header on a redirect from example.com to foo.example.com, then there's no reason not to preserve it on a redirect from one port to another on the same host. (Perhaps we should refuse to copy headers on a security downgrade from https to http?)