I hosted a simple app which responds with the request details for testing purposes: https://request-mirror.herokuapp.com/ (source: https://github.com/crodjer/request-mirror)
On 12:05 -0700 / 18 Apr, Paul McMillan wrote: > There seems to be some confusion about CORS (a hairy draft spec that > is not fully implemented in any browser, and not appropriate for > inclusion in Django at this time) and the "Origin" header (aka Web > Origin, rfc6454). > > http://tools.ietf.org/html/rfc6454 > https://wiki.mozilla.org/Security/Origin > http://www.w3.org/TR/access-control/#origin-request-header > > The Origin header defined in rfc6454 is compatible with the CORS > origin header, but does not require full CORS support from the browser > or the server to be useful. > > In my tests with Firefox and Chrome, both sent the origin header > properly when making potentially state-changing cross-origin requests > (both AJAX and standard form POST requests). > How did you test the form POST requests with firefox? For me, with a normal POST, Iceweasel (firefox for debian) 10 does not seem to be sending any origin headers but Chrome (18) is. MDN says that this should work firefox >= 3.5 (https://developer.mozilla.org/en/http_access_control#The_HTTP_request_headers) and the Origin header should be present: https://wiki.mozilla.org/Security/Origin#Origin_header_format I tried testing these cross domain (between the secure remote and local, between local aliases) through HTTP Post, but the browser never complained or did a Preflighted request (HTTP OPTIONS request) or sent back the origin header. But it apparently isn't with mine (Hopefully I am doing something wrong here) > My suggestion here is to include optional support for the Origin > header as follows: > - if present and null, fail the CSRF check > - if present and not null, use in alongside the Referer header > - if absent, keep current behavior > > As a general rule, if a browser sends an origin header, that value is > more reliable (harder for malicious sites to manipulate, less often > stripped by firewalls, less often disabled by users) than the referer > header. This addition won't improve CSRF protection for older > browsers, but it also won't break anything for them. For users with > newer browsers, it should prevent CSRF even in cases when the CSRF > token is stolen due to misconfiguration or user error. > > -Paul I second this. The selective origin checking, though not completely, will improve CSRF protection for some clients. We can then be sure about an automatic increase in security with the shift towards such clients. -- Rohan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
