get_host will use X-Forwarded-Host by default

[danielrichman]

Here: https://github.com/mitsuhiko/werkzeug/blob/cbd049d88727936173386d2e80bb5ffa51fedd6e/werkzeug/wsgi.py#L141

I don't think that this is a safe default.
When using flask it gives any client the ability to set an arbitrary hostname in request.url.

This surprised me, since http://werkzeug.pocoo.org/docs/0.9/contrib/fixers/#werkzeug.contrib.fixers.ProxyFix exists to explicitly enable support for these headers (X-Forwarded-For, X-Forwarded-Host, ...).

And I think that this is misleading: http://werkzeug.pocoo.org/docs/0.9/wrappers/#werkzeug.wrappers.BaseRequest.trusted_hosts since a web server must not only “not route invalid hosts to the application”, but it must also delete any foreign X-Forwarded-Host headers.

[untitaker]

Yeah that's actually pretty terrible.

[untitaker]

It actually turns out this isn't a security issue.

• Both X-Forwarded-Host and Host can already be forged by the user, since they are user-provided headers.
• X-Forwarded-For, which contains the user's IP address, can be forged (and therefore ProxyFix should only be used behind, well, proxies), but get_host doesn't need or use that anyway.

[danielrichman]

I disagree: while the user can specify arbitrary Host and X-Forwarded-Host headers, Werkzeug—by its own admission—“trusts” the Host header in some sense:

This is the recommended setup as a webserver should manually be set up to not route invalid hosts to the application.
(http://werkzeug.pocoo.org/docs/0.9/wrappers/#werkzeug.wrappers.BaseRequest.trusted_hosts)

This documentation is at odds with the behaviour of the get_host function. Either

• it is correct to trust the X-Forwarded-Host header by default, in which case the above documentation for trusted hosts is wrong, since it implies that if your web server sanitises Host you are safe; (it should mention that the web server should not route requests with invalid X-Forwarded-Host to the application?)
• or, get_host shouldn't trust X-Forwarded-Host by default.

There are cases when you need to be able to trust the Host header. For example:

• some SSO systems
• generating external urls to be used in, say, emails (potential phishing attacks?)
• etc...

Therefore, I personally believe that it should not trust X-Forwarded-Host default. However, as I've explained above, I believe there to be a documentation bug even if you disagree with me.

[untitaker]

Can't argue with that.

[mitsuhiko]

I'm a bit confused about the exact issue here but I'm not opposed to changing it. In any case the documentation should clearly mention this behavior.

The way the system works is this: the server has two sources for where the host can come from: the X-Forwarded-Host and the Host header. Both of which can be modified by the client. If you have a proxy in front you can sanitize them. Alternatively to sanitizing you can use the trusted_hosts parameter which Werkzeug will use to ensure that the host is in the list of trusted hosts. If it is not, a SecurityError is raised which will abort the request.

There are cases when you need to be able to trust the Host header. For example:

You cannot trust the host parameter. That's entirely impossible because nothing stops a client from forging the request. What you can do however is to make sure you only allow a single host value (by setting the trusted hosts to a list of that one host that is valid).

I'm not ruling out I'm wrong on this but I would love to hear where the mistake in thinking is.

[danielrichman]

So the 'mistake' is the documentation; AFAICT nothing mentions this behaviour, and documentation for other things (ProxyFix and Request.trusted_hosts) imply untrue things (that is, the presence of X-Forwarded-Host in ProxyFix implies that it is not used by default, and trusted_hosts should mention that if the webserver is to sanitise the request it must also sanitise X-Forwarded-Host).

However, this 'mistake' would also be fixed by changing the behaviour of get_host; that is, ignoring X-Forwarded-Host. Indeed, if those two lines were removed, then ProxyFix could be enabled if you desired the old behaviour (which kind of makes more sense to me).

I guess I've been simultaneously arguing both points in the same issue.

If you have a proxy in front you can sanitize them. Alternatively to sanitizing you can use the trusted_hosts parameter which Werkzeug will use to ensure that the host is in the list of trusted hosts.

I think that ultimately what I'm saying is that while people are likely to sanitise the Host header (as a side effect of vhosting / if they need it to be sanitised), most people won't think of X-Forwarded-Host.

I believe that it's quite likely that this could catch someone out, if they don't happen to read that section of the docs. Having to explicitly enable support for X-Forwarded-Host feels like a safer default.