5 ms·

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

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” 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.

probablyfiction 12y ago
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. EDIT: Looks like I am wrong on HN. Damn.
- ZoFreX 12y ago
  > A new random value for each request is essential to maintain the integrity of the measure No it isn't - Having CSRF tokens be unique per-session is perfectly adequate.
  - 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 ago
      That 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 ago
        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.
    - ZoFreX 12y ago
      Yeah, 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 ago
      The 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.
- sisk 12y ago
  Not necessarily. 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. [0]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...
- dsjoerg 12y ago
  Don't worry, everyone on HN is wrong.
  - georgemcbay 12y ago
    Not true, I once saw a comment on HN that was correct.
    - Mahn 12y ago
      Which one?
      - OvidNaso 12y ago
        The one that said all are incorrect.
  - antsar 12y ago
    This is quite paradoxical. :)
    - heinrich5991 12y ago
      It's just not true, i.e. false. 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.
      - malka 12y ago
        http://aeon.co/magazine/philosophy/logic-of-buddhist-philosophy/ http://aeon.co/magazine/philosophy/logic-of-buddhist-philoso... found this on hn a while ago. You might find this relevant to the logical paradox you are exposing
        pluma 12y ago
peter_l_downs 12y ago
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.

probablyfiction 12y ago

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. EDIT: Looks like I am wrong on HN. Damn.

ZoFreX 12y ago
> A new random value for each request is essential to maintain the integrity of the measure No it isn't - Having CSRF tokens be unique per-session is perfectly adequate.
- 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 ago
    That 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 ago
      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.
  - ZoFreX 12y ago
    Yeah, 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 ago
    The 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.
sisk 12y ago
Not necessarily. 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. [0]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...
dsjoerg 12y ago
Don't worry, everyone on HN is wrong.
- georgemcbay 12y ago
  Not true, I once saw a comment on HN that was correct.
  - Mahn 12y ago
    Which one?
    - OvidNaso 12y ago
      The one that said all are incorrect.
- antsar 12y ago
  This is quite paradoxical. :)
  - heinrich5991 12y ago
    It's just not true, i.e. false. 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.
    - malka 12y ago
      http://aeon.co/magazine/philosophy/logic-of-buddhist-philosophy/ http://aeon.co/magazine/philosophy/logic-of-buddhist-philoso... found this on hn a while ago. You might find this relevant to the logical paradox you are exposing
      - pluma 12y ago

peter_l_downs 12y ago

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.