Add Host extractor

[tbillington]

Motivation

This pr closes #826, implementing the host extractor.

Solution

1. Check the host portion of the uri to see if it's already been provided, returning if it has
2. Read from the "host" header value and return if it was present
3. Return an empty string if neither strategy yielded a value

[davidpdrsn]

Good stuff! Thanks for working on this 😃

[davidpdrsn]

The code looks good!

Wanna add an entry to the changelog as well? Then we can merge this.

[davidpdrsn]

Thanks!

[bluetech]

I don't think axum should trust X-Forwarded-Host blindly. The X-Forwarded-* headers are meant to be set by proxies, but a client is free to set them itself, so they should only be trusted when axum is running behind a proxy which sets or santitizes them. But this is circumstantial, especially X-Forwarded-Host is not set often. This will be a security issue if someone ends up using the Host extractor for something security-sensitive.

Here's a recent article about X-Forwarded-For, which is more complex/sensitive, but the gist is also relevant for X-Forwarded-Host.

[tsing]

@bluetech I guess it also applies to the Host header as the a client is also free to set the Host header given the Axum is not running behind a proxy.

[bluetech]

The client is supposed to set the Host header - it is expected. But the client is not supposed to set X-Forwarded-Host - if it does, that's unexpected. But it's still possible, so it must be considered.

[bluetech]

My suggestion is to make it configurable, like Django does.

[tbillington]

I'm struggling to see the practical implication.

• The application developer doesn't see which header the host came from
• The proxy will set x-forwarded-host if it is set up to, clobbering the user host in the process
• Fallsback to host header, which the user is supposed to set
• Optionally it could have been pulled from x-forwarded-host which the user set, but if we're already relying on them to inform us which host then does it matter?

[tbillington]

Unless the user is somehow able to override the proxys set header, I don't know enough about proxy servers to know what's common/possible.

[davidpdrsn]

@bluetech clients can also set the Host header to whatever they want.

curl localhost:3000 -H "Host: foobar"

[examples/hello-world/src/main.rs:25] &headers = {
    "host": "foobar",
    "user-agent": "curl/7.64.1",
    "accept": "*/*",
}

What makes x-forwarded-host different? Seems to me like you can never trust data from clients and have to be careful regardless which header you look at.

[jplatte]

Hm, can JavaScript fetch set x-forwarded-host from the browser? Since it's checked first, that would allow to "override" the host set by the browser itself.

Edit: Not forbidden (would've been surprising to see an x-something forbidden, honestly)

[bluetech]

I started writing a longer explanation, but I found an article which does so already: https://portswigger.net/web-security/host-header/exploiting. Also https://portswigger.net/web-security/host-header.

[davidpdrsn]

Still seems to me like devs are gonna have to validate the host header regardless.

@bluetech what do you think about this:

What makes x-forwarded-host different? Seems to me like you can never trust data from clients and have to be careful regardless which header you look at.

[davidpdrsn]

I've spoken to the lead maintainer of actix-web and think we should keep things as they are now, but add a note to the docs about the security risks. I'll do that.

[bluetech]

A warning is good, thanks.

I would still recommend following what Django does, namely ALLOWED_HOSTS (to validate Host - must be specified) and USE_X_FORWARDED_HOST (to opt into using X-Forwarded-Host when it's safe - default false). Because a lot of people won't read the docs and won't bother to validate the host which will expose them to attacks.

I also looked at what Ruby on Rails does -- they once trusted X-Forwarded-Host but made some changes (I'm not sure what exactly... I'm less familiar with rails) - see rails/rails#29893.

I look to Django and Ruby on Rails because they're the most popular web frameworks and have had to deal with every security issue under the sun, so "just do what they do" is a decent heuristic.

[davidpdrsn]

Axum doesn't have something similar to Rails' url_for. Our closest thing is Redirect but still requires using piecing things together themselves. Axum doesn't implicitly use the host behind the scenes. To me this makes it seem like a different thing. That seems like the crux of Rails' issues.

[bluetech]

Right, I guess it depends on what is the usecase for the Host extractor in the first place.