On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant <l.plant...@cantab.net> wrote: > On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote: >> As for the vulnerability -- it's only there if you implement it >> yourself. If you send the initial login form over SSL (we do it this >> way for various reasons), the cookies are never prone to be >> intercepted. > No, the vulnerability we are talking about is there even if *you* don't > send the forms over HTTP, because the MitM can insert the forms > themselves (and send a matching CSRF cookie) into any page served over > HTTP, and have those forms target HTTPS connections, and submit them > automatically by javascript. It's not about cookies being intercepted, > it's about them being set by a MitM over HTTP.
If you use a separate *secure* cookie for CSRF over SSL then it's not possible to submit data from an unsafe page to a safe processor. Secure cookies are only sent to SSL targets so it's not possible to intercept the cookie by any means. I suggest you enforce that by default (if CSRF_ALTERNATIVE is False). Now if CSRF_ALTERNATIVE is True, feel free to use the same cookie for HTTP and HTTPS and rely on the REFERER header. This will of course break for a small minority of internet users, probably tech-savvy ones who are respected enough to convince other people not to use my application. Of course if this is a true MitM attack, the attacker could just take your cookie and forge a request of his own, including a perfectly fine REFERER header. -- Patryk Zawadzki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
