lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 01 Dec 2013 10:06:30 +0100
From: Marc Nimmerrichter <marc.nimmerrichter@....at>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Seems like Coinbase Security Team doesn't
 know how their cookie works

>> While i don't see the point of saving the csrf token in a cookie i must say
>> that in every fucking programming book there is written that tokens should
>> be regenerated after logins.
>>
>> Or maybe i am just crazy or there are some other factors i did not
>> considered?
> Cookies don't completely remediate Injections and CSRF (as you can see).

I'd say that cookies never remediate CSRF, but are rather the cause of 
CSRF. So a CSRF token stored in a cookie doesn't make sense. It should 
be stored in a hidden field for example.

 >> Or maybe i am just crazy or there are some other factors i did not
 >> considered?

You said that you could perform actions on the victim's account by 
simply setting/knowing the CSRF token, is that right? So to me it seems 
as if they were using the CSRF token for authentication rather than for 
CSRF-prevention. If this is the case, then they have 2 vulnerabilities 
here: Session fixation and CSRF.

Marc

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists