Thanks for the info! Brian
On Mon, Oct 25, 2010 at 8:44 AM, Tom Evans <tevans...@googlemail.com> wrote: > 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<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Brian Bouterse ITng Services -- 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.
