-
Notifications
You must be signed in to change notification settings - Fork 1
Cross-Origin Protection #892
Comments
Raising an exception would make a mess of the code, and require checks in many places. I'm going to do what we do if the cookie has been edited or altered by hand and is invalid and just return no user, which just returns a |
# We rely on "secure;HttpOnly" cookies to prevent cross-site GET requests, and use # this Origin header checking to protect against cross-site POST and DELETE. Browsers # will prevent XHR JSON requests by using a pre-flight check, but form POSTs definitely # work and can be protected against this way. # Relevant to isaacphysics/isaac-app#892
We also don't protect registration this way, since it's not an authenticated request. I don't know how best to extract the checking code; to check authenticated requests it wants to be in |
As your example and the paper last week mentioned that Cross Site Request Forgery can happen pre-auth, I would say it is sensible to move the Exception form the auth.exceptions subpackage (to which one I don't know off the top of my head). |
(That CSRF paper, for reference: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7961990&isnumber=7961936&tag=1) |
Uh oh!
There was an error while loading. Please reload this page.
After adding logging of
Referer
andOrigin
headers, it is already clear that many browsers do not addOrigin
headers to same-originPOST
requests.The original authors of the RFC that led to the header suggest that
Origin
headers which are missing ornull
, or on an allowed whitelist, should be treated as acceptable; but that requests with a mismatchedOrigin
should be blocked. This affords users with a modern safe browser that does send the headers properly a better degree of protection from CSRF and XSS attacks. We should respond to requests with invalid origins with theCrossSiteRequestForgeryException
and a403 Forbidden
.I don't know if we also want to use the
Referer
header in cases where thePOST
has noOrigin
? And byPOST
I really mean all state changing requests.This obviously affords no protection against scripts outside of browsers where headers can be spoofed, but that's not CSRF or XSS.
The text was updated successfully, but these errors were encountered: