We can't trust the hostname in request.base_url #5
Bug report ultimately due to @danielchatfield, who said (about some PHP modules)
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:
... which makes the advice here arguably misleading:
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).
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.