You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
The text was updated successfully, but these errors were encountered:
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.
A HTTP Referer [sic] check was added in commit b1b164f for HTTPS sites. Its motivation is:
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).
The text was updated successfully, but these errors were encountered: