I'll reply to several emails at once here: > If we add Origin checking, could we then allow a missing referrer and token?
Yes, we can support the origin header and allow a missing referer. There's a ticket for that here: https://code.djangoproject.com/ticket/16010 and I agree that it's long overdue. Do we have any information on whether the referrer meta tag also influences the origin header? If it doesn't, this whole conversation is a bit pointless... > Aren't there existing security mechanisms to handle these situations? > It seems like this is sending the wrong message. Django should be > pushing developers and admins for the best solution to security and > privacy concerns. > > Prevent HTTP when using HTTPS: use HSTS. (Apparently not supported by IE11 > [0]) HSTS fixes the problem after the first visit, it can't fix the problem before the user has visited the site (or ever in IE11, or for sites which need unencrypted subdomains, or which are served at a subdomain). We need to provide the best protection we can, so we still need to check the referer. As Aymeric said, the XFO header doesn't do anything to prevent a MITM from sending whatever they want. > However, In my opinion, the user's privacy needs go beyond this one > scenario. I will remind you that suppressing the referer header in question does _absolutely nothing_ to enhance your user's privacy since it is only relevant when the user is making a post from one page of your site to another page of your site. Your webserver logs each of those requests, and so where the traffic came from is immediately obvious. I agree that chrome should support no-referrer-when-crossorigin, but since all of this conversation is in reference to a proposed standard which is not finalized yet, I would argue that this is an issue you can and should bring up with the editors of the referrer-policy draft spec (last revised 6 days ago). If they update the spec, I expect that chrome will be updated to match it in short order. > Is there detailed documentation on the type of attack this REFERER > check guards against? Whether Django documentation or external > documentation is fine. I would like to have a firm understanding of > the real problem and how this solves it. We don't have detailed documentation about every type of CSRF attack that we defend against (such a document would be impossible to maintain). However, I will try to lay this out more clearly for you here. setup: user -> mitm -> server Server is configured properly: * HTTPS with good ciphers * long-lived HSTS including all subdomains, served from yoursite.com * X-Frame-Options: Deny * Secure cookies * permanent redirect from http to https The user has never been to your site on this computer before (maybe they're logging in from a library computer, or a friend's computer, or this is their first visit to your site). The user types yoursite.com into the address bar and hits enter. The mitm sees the request for http://yoursite.com, and rewrites the 301 redirect response your server sends to add a csrftoken=aaa cookie. The user continues to your website. They log in. Some time later, the user browses to aol.com (or any other insecure site). The mitm sees this traffic, and on-the-fly, rewrites the html that aol.com serves to include a script which posts a form to your server, including a form field containing the CSRF value that the attacker now knows (because the attacker set the csrf cookie in the first place). This post (because it is prepared by the user's browser) includes all cookies set for your domain (including the session and the csrf token). The user's browser may or may not send a referer with this post, but in either case the origin does NOT match your original server, and Django rejects the attack. If we remove the referer check in Django, this attack is accepted (since it has a correct matching CSRF token and a valid user session), and your application is compromised. For websites and browsers that don't support HSTS (or websites which aren't at the top level domain, or which don't include all subdomains in the HSTS), this attack works every single time the user visits your page. For browsers which do support HSTS (and your server has it enabled) the attack is viable any time until the first time a browser visits your page. Django has to provide the _best_ possible CSRF protection it can, so it is not an option to exclude protection for the first visit, or for sites which use non-https subdomains or parent domains, or for browsers that don't support HSTS. Hopefully you see why this check is important. You should find out whether the referrer metatag also influences the origin header - if it doesn't, fixing the ticket mentioned above would make most of your concerns go away. Regards, -Paul -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAO_YWRVbcPfm%2BXvDFTXhP1UuUTmyjoQiMJpMOeNqKMswwGL--g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
