He captured a cross-site request forgery token which was valid for all users.
EDIT: Looks like I am wrong on HN. Damn.
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.
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.
No it isn't - Having CSRF tokens be unique per-session is perfectly adequate.
There's a good explanation here: http://stackoverflow.com/a/25475141/240921
Just reduces the risk surface a bit.
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.
I've never heard of using the CSRF token itself to answer the "who is this user" question. Has PayPal been using a single value for both the session cookie and the CSRF token? That seems fundamentally broken to me but it's more likely I'm misunderstanding the bug.
Furthermore, CSRF mitigation does not have to depend on a session existing. The CSRF token value can written to a separate cookie unrelated to the session, which value can be randomly modified with every page load. For every page view, the CSRF token on the form would be different, and would be matching an ever-changing CSRF cookie value.
> There is no reason why a session can only be created
> after login.
In your second scenario, while of course you could store a random value in a "CSRF cookie" on every page load, of what use could it be if you don't also store the "last CSRF cookie value" somewhere on the server and compare against that on new requests?