5 ms·
Someone (or even more frightening, multiple someones) at Paypal didn't understand the point of CSRF tokens. A new random value for each request is essential to
by probablyfiction 12y ago
Someone (or even more frightening, multiple someones) at Paypal didn't understand the point of CSRF tokens. A new random value for each request is essential to maintain the integrity of the measure. CSRF tokens should never be used as a type of global authentication value. The fact that this made it to production is mind-blowing.
EDIT: Looks like I am wrong on HN. Damn.
- ZoFreX 12y ago> A new random value for each request is essential to maintain the integrity of the measure No it isn't - Having CSRF tokens be unique per-session is perfectly adequate.
- mike-cardwell 12y agoFrom what I can see, it should be good enough to just use the same session id which is stored in the cookie as the CSRF token. If an attacker has your session id, then CSRF is the least of your problems. I don't know why people come up with more complicated schemes... Am I wrong?
- sisk 12y agoThat would make tokens valid across different applications that share a session. A compromise of one application would then jeopardize all your applications. Just reduces the risk surface a bit.
- ZoFreX 12y agoA compromise of any session ID is more serious than losing the CSRF token anyway. Once I have your session ID I am you from the POV of the server, so who cares about the CSRF token? Also, you may well have different session IDs across different applications anyway - pretty good idea, if you want to be able to selectively deauthorise logins.
- ZoFreX 12y agoYeah, you can. There's a couple of reasons you might not want to but there's nothing seriously wrong with doing that. There's a good explanation here: http://stackoverflow.com/a/25475141/240921 http://stackoverflow.com/a/25475141/240921
- StavrosK 12y agoThe problem with that is that, if you steal the CSRF token (which is easier to do than a session ID hidden in a cookie), it's game over.
- sisk 12y agoNot necessarily. CSRF tokens don't have to be unique per request. That's useful for things like preventing double submissions, ensuring order, or invalidating requests that are still in an active session but have timed out. However, it isn't necessarily more secure than having a secret tied to a user session and generating a token with that secret (which would, by itself, mean that any single token could continue to be used for the life of the session). See OWASP's recommendation[0] which includes: In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress. [0]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...
- dsjoerg 12y agoDon't worry, everyone on HN is wrong.
- georgemcbay 12y agoNot true, I once saw a comment on HN that was correct.
- antsar 12y agoThis is quite paradoxical. :)
- heinrich5991 12y agoIt's just not true, i.e. false. Assume that everyone was lying. Then this statement is true, but as a lie it must be false. Contradiction. So this case is not possible. Asumme that not everyone was lying. E.g. some other post is false. Then this statement is false. This fits together if you have another post that is false.