Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We can't trust the hostname in request.base_url #5

Closed
danielrichman opened this issue Oct 3, 2014 · 9 comments

Comments

Projects
None yet
2 participants
@danielrichman
Copy link
Owner

commented Oct 3, 2014

Bug report ultimately due to @danielchatfield, who said (about some PHP modules)

When checking the URL in the WLS-Response both the Drupal and the Symfony modules implicitly use the Host header, this would be reliable on server setups with virtual hosts (where the Host is used to determine which site should be displayed) but the majority of Cambridge websites do not appear to be setup this way (they will happily return a response regardless of what the Host is).

Werkzeug/flask using python-raven also suffers this issue. In fact, it's far worse since Werkzeug will blindly trust a 'X-Fowarded-Host' header, no matter who sets it:
https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/wsgi.py#L141

... which makes the advice here arguably misleading:
http://werkzeug.pocoo.org/docs/0.9/wrappers/#werkzeug.wrappers.BaseRequest.trusted_hosts

Setting trusted_hosts may be the easiest solution; will update later.

@danielchatfield

This comment has been minimized.

Copy link

commented Oct 3, 2014

Was just about to create an issue about this.

@danielchatfield

This comment has been minimized.

Copy link

commented Oct 3, 2014

👍 I like this solution.

@danielrichman

This comment has been minimized.

Copy link
Owner Author

commented Oct 3, 2014

@danielrichman

This comment has been minimized.

@danielrichman

This comment has been minimized.

Copy link
Owner Author

commented Oct 3, 2014

@danielrichman

This comment has been minimized.

Copy link
Owner Author

commented Oct 4, 2014

Re #6: I agree with you.

In fact, no such similar solution can work: if we can convince Bob that he is a back-end server for Eve's website, then Eve can ultimately always man-in-the-middle the auth process, stopping once Alice has authed and keeping the authenticated session for herself.

Will update docs.

I claim that there is something to be said for having a params token anyway: it makes the WLS-Responses appearing in your access logs useless (well, more useless than they already are due to the 'issue' parameter).

@danielchatfield

This comment has been minimized.

Copy link

commented Oct 4, 2014

I agree that keeping the params is good - would prevent some other attacks.

In the library for the wordpress plugin I've started it requires that either $trusted_hosts is passed or a flag set (either an environment variable or an argument to the verifyUrl) that essentially means the server or the application consuming the library (in this case the wordpress plugin) takes responsibility for checking it.

The Wordpress plugin sets the trusted host by parsing the site_url config option.

@danielrichman

This comment has been minimized.

Copy link
Owner Author

commented Oct 4, 2014

I like this idea.

danielrichman added a commit that referenced this issue Oct 4, 2014

@danielrichman

This comment has been minimized.

Copy link
Owner Author

commented Oct 4, 2014

Closed by ac73152

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.