net/http/cgi: local Location can be misparsed as protocol-relative URL

[neild]

A CGI handler may return a Location: header to return a reference to some document rather than the document itself.

When the Location: header value starts with a / and net/http/cgi.Handler.PathLocationHeader is set, net/http/cgi parses the Location as a URL and passes it to PathLocationHeader.

When the Location is a protocol-relative URL such as //host/path, this passes a URL with a hostname to PathLocationHeader, which is probably surprising.

This was reported to us as a potential vulnerability. Given that the Location header comes from a CGI program, where a malicious program likely has much more exciting opportunities for misbehavior, we don't feel this constitutes a vulnerability. However, it would be reasonable for net/http/cgi to better handle protocol-relative URLs in Location headers for correctness/hardening.

[seadog007]

RFC 3875 (The Common Gateway Interface (CGI) Version 1.1) defines that

client-Location = "Location:" fragment-URI NL
local-Location  = "Location:" local-pathquery NL

which

fragment-URI    = absoluteURI [ "#" fragment ]

and

A valid absoluteURI
always starts with the name of scheme followed by ":"; scheme names
start with a letter and continue with alphanumerics, "+", "-" or ".".

I think Location: //example.com should be treated as local-Location, and not client-Location

So even though RFC 9110 (HTTP Semantics) + RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) state that the network-path reference (//example.com) can be valid HTTP Location header, the CGI Server shouldn't treat it as the HTTP location.

The Apache httpd also does the same thing, see https://github.com/apache/httpd/blob/2.4.67/modules/generators/cgi_common.h#L496-L511

So according to the standard, and for the legacy compatibility, this is not an actual issue.