go: net/http: insufficient sanitization of Host header

The net/http client does not sufficiently sanitize or check the validity of the Request.Host field. A maliciously-crafted Host field can inject request headers or entire new requests into the sent request. For example, setting Request.Host to "hostname\r\nX-Header: oops" adds an X-Header: oops header to the request.

Whether this is a vulnerability or just a bug depends on whether the Request.Host field is expected to be secured against untrusted inputs. We don’t document this one way or the other. Exploiting this in practice seems difficult, since it requires requests to be sent using an unsanitized and untrusted Request.Host value, so if this is a vulnerability it seems reasonable to treat it as PUBLIC track. Either way, we should fix it.

This is a continuation of #11206, which reports the same issue but had an incomplete fix.

Thanks to @bartekn for reporting this issue.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 7
  • Comments: 23 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Have to agree with @andresvia here. This essentially broke everything using docker. In a patch version update as well.

Thank you for this change. This does cause an issue for unix sockets that have hostnames starting with a slash. I think we are seeing the community that uses sockets now have to react to this change and put in conditional logic to check their host and if it begins with a slash or ends with .sock change the host name to something like localhost. Is it possible to have this baked into net/http host header validation?

@jmurret I will dare to say that the security fix went too hard and broke a feature which many of us relied on and now there’s really no right (clean) way to proceed, if the validation gets baked, workarounds will need to remain because there will be always people running some go release which doesn’t have the thing baked. I’m sorry I know I’m not really commenting anything useful, I’ll just move on with my life 😄 and let you guys think about what you just did.

Thank you for this change. This does cause an issue for unix sockets that have hostnames starting with a slash. I think we are seeing the community that uses sockets now have to react to this change and put in conditional logic to check their host and if it begins with a slash or ends with .sock change the host name to something like localhost. Is it possible to have this baked into net/http host header validation?

Only thing left to resolve is the backports, so I think we can close this one.