I'll have to look at this in more detail, but two notes, off-the-top. First, port 80 is kept open because the browser will try port 80 if the user types in the url without the protocol. On port 80 all we do is issue a redirect to https, but the client will have spilled the cookies by then.
Second, the most like scenario for this to happen is with a wireless MITM. E.g. an attacker sits in, or near a coffee shop, or office, with a laptop setup as an AP, trolling for connections from unsuspecting users. If anyone connects, the laptop can be used as a MITM. So, for example, when the user types the url and hits port 80, the MITM can create an https connection to the target site, and return it via http. I'm not certain there's a csrf attack here, but I suspect there is. On Wed, Feb 9, 2011 at 11:28 PM, Ian Clelland <clell...@gmail.com> wrote: > On Wed, Feb 9, 2011 at 11:51 AM, Brian Craft <bc...@thecraftstudio.com> wrote: >> I thought, rather, that the csrf token was a cookie that was put in a >> hidden form field. > > You're absolutely right; I wasn't thinking about that side of the token. > >> With firebug or webkit dev tools you can see the django csrf token in >> the cookies. I would also refer you to middleware/csrf.py, where you >> can see it doing the set_cookie. >> >> I thought the security of the csrf token relied on the fact that the >> 3rd party wouldn't know what value to put in the hidden form field. >> The csrf middleware is, I believe, validating the value in the form >> field, against the value in cookie. But when it creates the form, it >> uses the value in the cookie. >> >> If the token is stored in an insecure cookie, it can be sniffed. Then >> I don't understand what prevents the attacker from constructing a >> valid form. > > If you want a secure cookie, that means that your entire site (or at > least the form-handling bits) must already be protected by SSL (since > a secure cookie will only be returned over an SSL connection). > > The threat model you are proposing, then, sounds like this: There is a > website, running Django, using Django's CSRF protection, in which all > of the form-handling views are only accessible over HTTPS, but there > are other resources in the same domain (or its subdomains) which are > accessible over HTTP. > > Further, there is an attacker, who can sniff the unencrypted HTTP > traffic, and can construct an HTML page at a different site (this is > Cross-Site Request Forgery, after all) > > A lot of the potential damage seems to be mitigated by another check > in django/middleware/csrf.py, for HTTPS requests only, that inpects > the referer header of the incoming request, to ensure that the browser > was not submitting the form from a different site. To get around that, > the attacker would have to be able to construct a form on the > SSL-protected site (a serious html-injection vulnerability would have > to be present), or cause the request to be submitted over plain HTTP > -- but the site is already HTTPS-only, so there shouldn't be any > form-handling code listening on that port. > > Does this threat model correspond to what you're thinking? If so, I > don't see away around the CSRF protection (at least, not one that > involves the victim's browser) > > > -- > Regards, > Ian Clelland > <clell...@gmail.com> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
