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

[Ilya Skriblovsky]

> 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.

-- ilya

пт, 17 мар. 2017 г. в 11:18, Glyph <glyph at twistedmatrix.com>:

On Mar 15, 2017, at 1:20 AM, Ilya Skriblovsky <ilyaskriblovsky at gmail.com>
wrote:

Ok, so in the sort term you are suggesting to change Request.URLPath


Yes.

(uppercased method? Hmm)


Like I said, not a great interface, overall :-).

to use Host header instead of getRequestHostname and to change Klein to use
it instead of Request.getHost(), right?
Sounds wise and reasonable :)


OK, glad you agree :).

But I'd like to add one more thing. In order to build correct external URL
we need to know is it http or https. Currently URLPath is using
Request.isSecure(), but it is not sufficient since Request.isSecure() just
checks if backend connection is SSL while encryption is often terminated at
a reverse proxy. Can we add "useXForwardedProto=False" argument to
Request.URLPath() and check X-Forwarded-Proto header if it is true? And may
be add "useXForwardedHost=False" too to simplify setting up a reverse proxy
(with a bold red warning in docstring that it can be set to True only if
reverse proxy is correctly configured to drop corresponding
client-specified headers). What do you think?


I think that for starters, it would make more sense to just fix it to
*always* honor forwarded-for and x-forwarded-for headers.  The code calling
request.URLPath(), in a given Resource, or application, is highly unlikely
to know whether it wants to honor (x-)forwarded-for.  The code that might
know about this sort of configuration would be the thing that constructs
the Site object, but I'd be much happier to just get a change that always
honors it first, and then figure out how to customize it later.

-glyph

_______________________________________________
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/20170317/d128e893/attachment.html>