On 18/04/12 20:05, Paul McMillan wrote: > 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.
That does sound like a useful additional behaviour. One query: are you sure it is harder to manipulate? In particular, I remember from a while back that Flash allowed some headers to be manipulated, which caused problems, and they fixed it by blacklisting some headers, I think including referer. Did they also fix Origin? The vulnerability I'm thinking about is this one I think: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html Luke -- "My capacity for happiness you could fit into a matchbox without taking out the matches first." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
