Pivotal paragraph:
"We have found out that an Attacker can obtain the CSRF Auth which can be valid for ALL users, by intercepting the POST request from a page that provide an Auth Token before the Logging-in process, check this page for the magical CSRF Auth “https://www.paypal.com/eg/cgi-bin/webscr?cmd=_send-money”. At this point the attacker Can CSRF “almost” any request on behave of this user."
He captured a cross-site request forgery token which was valid for all users.
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.
I'm having a hard time understanding this. My mental model of the situation is that websites figure out which user is interacting with them via a "session" cookie, which is only set once the user successfully authenticates. The CSRF "token" is a value associated with this session (that may or may not change on every request) that's included with all client-side requests as a way to guarantee that whoever is making the requests is doing so from the site's pages. For instance, if I log in to Facebook, then in a new tab open up 'somemalicioussite.com', the malicious site might make force my browser to make a request to 'facebook.com/some-private-api-endpoint' to try to figure out who I am. Because it doesn't have the CSRF token, it fails.
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.
Note that the author does not suggest that the global CSRF token can be exploited without another user's intervention; if I understood the article correctly exploiting that token for evil would still require getting someone to click your malicious link (i.e. performing a CSRF attack)
Ah, perfect, that's the part I was missing. Just sat down and watched the video demonstration (https://www.youtube.com/watch?v=KoFFayw58ZQ#t=200) – at 3:20 he navigates the victim's browser to a site controlled by an attacker. Thanks!
There is no reason why a session can only be created after login. Think about using Amazon.com anonymously. You can add books and things to your cart without logging in. Those are stored in an anonymous session that is unique to you.
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.
You're right, I didn't type carefully above – I mean that a session cookie can only be used to identify the current user of the website with an existing customer once the user has authenticated with the customer's credentials.
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?
He captured a cross-site request forgery token which was valid for all users.