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

Remove Referer check #46

Open
Lekensteyn opened this issue Dec 13, 2017 · 1 comment
Open

Remove Referer check #46

Lekensteyn opened this issue Dec 13, 2017 · 1 comment

Comments

@Lekensteyn
Copy link

Lekensteyn commented Dec 13, 2017

A HTTP Referer [sic] check was added in commit b1b164f for HTTPS sites. Its motivation is:

+       // if the request is secure, we enforce origin check
+       // for referer to prevent MITM of http->https requests

I doubt that this check will add much value. The token is not secret, it just needs to be unpredictable. Since httpOnly is not set by default, the cookie can also be leaked through XSS.
An open redirect vulnerability would also bypass this check.

There is at least one case where this breaks, when (Firefox) users disable the Referer header. What about using the Secure cookie flag instead? In that way, a different token will be sent to the http and https origins and even a passive adversary cannot see the token of the secure origin.

Related comment: #11 (comment)

Edit:
even with the Secure flag set, it would not help with existing cookies (which have a default lifetime of one year). Any cookies injected into a HTTP origin will also be sent to a HTTPS one.

A possible alternative for the referrer check here is the use of the SameSite attribute, although it will have the same problem as above (HTTP cookies can still be injected into HTTPS).

Assuming a passive adversary, a possible mitigation is the inclusion of the scheme in the cookie name or value. When the scheme does not match, treat it as invalid and send a new cookie (with the Secure flag set).

@fjorgemota
Copy link

Another option that's better (IMHO) is to add a list of trusted origins, so this check would check against a slice instead of checking if the URL is the same.

Django did the same and it seems to at least improve the situation where the backand and the frontend aren't on the same domain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants