[Twisted-web] internal vs. external hostname in Request.getHost9)

[Ilya Skriblovsky]

This thread is mostly about X-Forwarded-Host & X-Forwarded-Proto because
the original issue was inability of Twisted Web server to obtain it's
public hostname. X-Forwarded-For is another (and probably more complex)
story.

Django indeed dropped support for X-Forwarded-For, but it does support
X-Forwarded-Host [1] and X-Forwarded-Proto [2] on opt-in basis.

I'm agree that none of the headers should be trusted by default and that
opting-in should be done at Site level.

-- ilya

[1]:
https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-USE_X_FORWARDED_HOST
[2]:
https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-SECURE_PROXY_SSL_HEADER

пн, 20 мар. 2017 г. в 21:32, Tom Most <tommost at gmail.com>:

> On Fri, Mar 17, 2017 at 2:52 AM, Ilya Skriblovsky <
> ilyaskriblovsky at gmail.com> wrote:
>
> > The code calling request.URLPath(), in a given Resource, or
> application, is highly unlikely to know whether it wants to honor
> (x-)forwarded-for.
> You are right, I haven't thought about it.
> But I'm in doubt whether trusting X-Forwarded-* by default can damage
> security if Twisted app is running with naked HTTP(S) port exposed without
> reverse proxy that handles these headers.
> There are three headers:
> 1. X-Forwarded-For specifying original client IP and IPs of proxies
> 2. X-Forwarded-Host specifying original Host header from the client
> 3. X-Forwarded-Proto specifying original client's scheme
> (there is also new-style "Forwarded:" header but it is not widely used
> yet, AFAIK)
>
> X-Forwarded-For definetly can't be trusted if comes from untrusted client
> client. Fortunately we don't need it at all for generating URLs :) It will
> be in question when refactoring getClientIP() somewhen later.
>
> But can we trust X-Forwarded-Host & X-Forwarded-Proto? From the first
> glance it isn't a problem since we are using them to display URLs for the
> same client, so nasty client will get his nasty URLs, that's it. But if app
> is doing something like storing URL in DB or (more likely) sending an email
> with a link to another client, this would be an issue.
>
>
> It's not safe to enable support for X-Forwarded-For and friends by
> default, since you can't know how application code will use that
> information and in many configurations it may be spoofed by clients.
>
> A proper deployment which sets these headers looks like this:
>
> 1. Configure your frontend reverse-proxy (nginx or whatever) to discard
> incoming X-Forwarded-* headers and *set* X-Forwarded-* as appropriate.
> Note that X-Forwarded-For is actually a *list* of hops[1], so if you do
> this naively your server may append to the list! [2]
> 2. Configure your backend services to respect exactly the headers passed
> by your frontend.
>
> Note that this requires administrative action in two places, and that if
> you don't do the frontend config it will probably pass the headers through,
> allowing them to be spoofed.
>
> A non-exhaustive list of possible bad stuff I client could use spoofing
> for:
>
> 1. Evade IP-based access control (a reasonable defense-in-depth measure).
> 2. Evade pinning of user sessions to IP addresses or subnets.
> 2. Evade IP-based rate limiting, e.g. as discussed at [3].
>
> It's also probably worth noting that Django used to offer support for
> X-Forwarded-For and removed it[4]. X-Forwarded-* and friends just too
> varied in the wild to reasonably support.
>
> If Twisted is to support this in any way, I think that it should be opt-in
> support for the Forwarded header as specified in RFC 7239. This should be a
> parameter applicable to all of twisted.web.server rather than per-method
> call, since it's something the administrator needs to set.
>
> —Tom
>
> [1]: Standardized as Forwarded in https://tools.ietf.org/html/rfc7239
> [2]: Your frontend proxy should also validate Host is a domain you control
> to prevent cookie theft. Plus lots of other stuff. Web security is hard,
> and every default everywhere sets users up for failure.
> [3]: http://django-ratelimit.readthedocs.io/en/v1.0.0/security.html
> [4]:
> https://www.djangoproject.com/weblog/2009/jul/28/security/#secondary-issue
> _______________________________________________
> Twisted-web mailing list
> Twisted-web at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-web/attachments/20170320/c4424405/attachment-0001.html>