Validate Host header to prevent Host header injection

[ayushmanchhabra]

No description provided.

[ayushmanchhabra]

@Maikuolan

[guest20]

What could an invalid Host header be injected into? A reverse proxy is going to not be able to route it to a back-end and a custom app isn't ever going to find any content to serve...

Is this just incase your logging analysis platform is vulnerable to xss?

[Maikuolan]

I can definitely see the value of this for certain kinds of APIs, but I don't think it would be necessary for every kind of API out there, and I imagine, could potentially get in the way of normal operation in some cases. A bit contextual, I think. That would then also raise the question of whether we should include contextual checks in the checklist, or leave them be, just including the most standard, common checks in the checklist (and honestly, I have no idea there; it may be a bit more work, but may also be a bit more useful for people that way.. or may not; I don't know).

Does anyone else have any thoughts regarding this that they'd be willing to share? For now, I'd rather just leave this pull request open and postpone any decision for whether to merge it or not until there's a bit more feedback from others.

[guest20]

This could be added as part of the Use HTTPS on server side recommendation under Access by adding "... and make sure the Host header matches the SNI".

This way the recommendation isn't a vague "maybe regex match the header" and also pushes the "no thanks" response all the way out to any loadbalancing / cdn / ssl terminating devices. It also makes it less likely that a random intern from the appsec team won't come and bother the developers

[ayushmanchhabra]

This could be added as part of the Use HTTPS on server side recommendation under Access by adding "... and make sure the Host header matches the SNI".

This way the recommendation isn't a vague "maybe regex match the header" and also pushes the "no thanks" response all the way out to any loadbalancing / cdn / ssl terminating devices. It also makes it less likely that a random intern from the appsec team won't come and bother the developers

421 Misdirected Request is exactly what I was thinking of! There have been cases where it is possible to redirect the website to another domain by tampering with the Host header. (Would that come under Host header injection or header based redirection?) My reasoning behind this was if the Host header is validated on every request, it would prevent that class of vulnerability.

If there is no host header validation, then the request will be forwarded as usual by thr reverse proxy right?

[guest20]

@ayushmanchhabra I believe you're thinking of "fronting", where the bad guy puts their infra on a popular service, and then uses a random good guy's dns names/certs to talk to the hosting providers' border proxy and they then set Host header to their own name so the reverse proxy routes traffic to their own infra behind the proxy:

good-website.com --> |aws-frontend-proxy | --> good-website.com app
badguy.evil -------> |                   | --> badguy.evil app

With this setup:

• everything unencrypted looks like traffic to good-website
• and the name and certs match (they point to the right IP for good-website)
• dns block lists can't include good-website.com
• a non-privileged proxy can't see the Host header (You trust the proxy to terminate https by installing its cert/CA)

I think this is one of the main "reasons" sketchy enterprise security products love to MITM'ing https traffic when you're in the office.

It's possible that mis-matched Host could also be useful for getting at apis behind a k8s cluster too (since you don't need the name in the Host header to resolve locally).

I'm sure somebody has written a howtos nginx/haproxy/caddie/træfic/etc to help prevent this kind of thing

[ayushmanchhabra]

This could be added as part of the Use HTTPS on server side recommendation under Access by adding "... and make sure the Host header matches the SNI".

This makes sense to me