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.
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.
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.
This is why I can't take philosophy serious anymore.
Examples like the "this statement is false" thing are just rife with equivocations and other blatant nonsense. Yes, there is such a thing as "neither true nor false", but every example for "both true and false" I've seen is based on lousy thinking and semantic games.
Also, as a JS programmer, the distinction between true/false/neither/ineffable is very familiar (i.e.: true/false/null/undefined, null denoting the absence of a value and undefined denoting the absence of a definition -- though of course in practice the distinction is rarely necessary resulting in a lot of confusion and unnecessary double checks).
It's got nothing to do with "mysticism". It's just arm chair linguistics.
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?
That would make tokens valid across different applications that share a session. A compromise of one application would then jeopardize all your applications.
A 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.
EDIT: Looks like I am wrong on HN. Damn.