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
| ||
|
Message-ID: <529AFC16.4090803@mni.at> 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