full-disclosure - Re: Seems like Coinbase Security Team doesn't know how their cookie works

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 linux-hardening linux-cve-announce 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/