On Mon, Oct 25, 2010 at 1:17 PM, Brian Bouterse <bmbou...@gmail.com> wrote: > I'm not an expert in security, but here is how I would answer the question. > The CSRF approach that Django 1.2 implements would prevent *most* of these > problems since the attack wouldn't be able to POST new data to the site by > stealing the cookie alone. IBM applies CSRF tags to each step the user > interacts with on the entire site, in a technique known as continuations. > These techniques only prevent *most* attacks though, the session can still > be hijacked just with a reduced window of opportunity. > I say *most* because if you can snoop on the HTTP traffic, you theoretically > could capture the in-plain-text CSRF token the server handed the user once > they were generated one (from being on a user account to reset my password > page). An attacker could form a valid POST using the CSRF just captured and > I think it would work. > Not even validating that the IP is the same for each CSRF would solve the > problem either considering these two users are probably going to be in a > coffeeshop, behind a NAT. > One possible solution would be to have some kind of hardware attestation or > browser attestation and tie session info to that. If anyone has any > thoughts on how this could be done, please let me know. > Brian > On Mon, Oct 25, 2010 at 6:47 AM, cootetom <coote...@gmail.com> wrote:
It's actually orthogonal to CSRF. CSRF protects you from a 3rd party web site maliciously enticing a user to initiate data changing requests to your site. It does nothing to protect a user from having their cookies jacked by a 3rd party user, and then stopping that user from maliciously using the credentials inferred from those cookies. That this is even news is surprising - it's hardly a new attack vector. The only new thing about it is it being hooked up to a web browser and showing live feeds of what is happening, which has probably opened the eyes of people who didn't think about it before. It's like saying 'Oh wow, you can see in plain text peoples emails on unsecured wifi networks' - well, durr, its a plain text protocol, and the whole 'unsecured nework' bit should probably give it away... If you don't want this to happen, then force the use of SSL throughout your site, and don't hand out session cookies over HTTP. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
