4 ms·

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" cook

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.

Mahn 12y ago
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)
- peter_l_downs 12y ago
  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 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!
legutierr 12y ago
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.
- peter_l_downs 12y ago
  > 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?

Mahn 12y ago

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)

peter_l_downs 12y ago
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 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!

legutierr 12y ago

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.

peter_l_downs 12y ago
> 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?