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?)

[manigandand]

If the sensitive headers can be copied for subdomains then why not for the same host without a port.

I expect the headers to be copied to the same host of the different ports.

Redirecting from api.gopherhut.com:80 to api.gopherhut.com:443 I expect the sensitive headers also should be sent.
Currently, this is not happening because we are checking for exact host matches from the different canonical host addresses.

func isDomainOrSubdomain(sub, parent string) bool {
	if sub == parent {
		return true
	}
	// If sub is "foo.example.com" and parent is "example.com",
	// that means sub must end in "."+parent.
	// Do it without allocating.
	if !strings.HasSuffix(sub, parent) {
		return false
	}
	return sub[len(sub)-len(parent)-1] == '.'
}

[asutosh97]

Yes, agree with what @manigandand said
Maybe we should just simply check the hostnames and leave out the ports when doing the check