-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
Add origin header checking #13
Comments
If understand it correctly, an app that would use only server-side Origin header checking alone would prevent CSRF in all browsers that implement the Origin header correctly. Clients with older browsers that don't send Origin headers then wouldn't be protected, and CSRF could still happen there. In relation to CSRF protection, the most important bit is that the Origin header is sent with an ordinary form submitted as POST (IIRC Firefox used to have issues with that). Does anyone know of some data about how well is the Origin header implemented in major browsers? Like from which version they send the Origin header, especially in normal POST submits. This might be interesting to know, because it could help determine how viable it would be to use just Origin header checking for CSRF protection. If e.g. 95% of browsers out there send Origin header with ordinary POST form submits, we might not need any other protection and could be alright with the remaining 5% being susceptible to CSRF (they're probably older browsers with other security issues anyway). Any detailed browser support data for this? |
For lenient header checking (requests missing the headers are accepted or it "fails open"), yes. Strict header checking over TLS should be fine if the site is OK breaking support for requests without the headers. Tokens are still the most robust solution, but strict header checking can make sense for embedded or IoT applications.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin#Browser_compatibility says the current versions of all browsers but no POST requests from Firefox. I don't see version numbers in https://caniuse.com/ |
Thanks for getting back to me. Yeh, I've seen the data both on Can I Use and MDN, unfortunately, they're not very detailed regarding the version and specifics of the POST forms and Origin header. I found a very good article on OWASP wiki (CSRF Prevention Cheat Sheet). TL;DR: They recommend to check both the Origin and Referer headers, and if they are both empty, then fail to process the request. On top of that, they still recommend using token validation (however they say it's possible to rely on just the header checking):
I've just tested Firefox (version 56), and unfortunately, it still has the issue with not sending Origin headers when POSTing forms... But at least it still sends the Referer header correctly. But I've always considered the Referer header to be unreliable as I remember some antiviruses and firewalls used to remove the Referer header for privacy reasons. I'm not sure if they can do that if the site is running on HTTPS, and on POST requests, but I guess it might be possible to mess with the headers through some browser extension. I'm not really sure what the state of Referer header filtering is in 2017. Although OWASP still consider the case where both Referer and Origin headers missing as very rare:
|
It is more robust than referrer checking and a nice addition to tokens.
http://seclab.stanford.edu/websec/csrf/csrf.pdf (proposed here)
https://wiki.mozilla.org/Security/Origin
The text was updated successfully, but these errors were encountered: