3 ms·
From 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 i
by mike-cardwell 12y ago
From 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.