4 ms·

Regarding CSRF - how would I be authenticated to do actions on bank.com when I'm on evil.com? It seems like the problem is at the level of login information so

Regarding CSRF - how would I be authenticated to do actions on bank.com when I'm on evil.com? It seems like the problem is at the level of login information somehow crossing domain boundaries? What stops a script on evil.com from going to bank.com to get a CSRF token and then including that in their evil request?

gavinsyancey 2y ago
When you logged in to bank.com, it set a cookie that your browser presents when it makes any request to bank.com, regardless of how it was initiated (i.e. it would still send the cookie on a cross-site XHR initiated by evil.com's JavaScript). > What stops a script on evil.com from going to bank.com... CORS
- alexashka 2y ago
  > it set a cookie that your browser presents when it makes any request to bank.com, regardless of how it was initiated Right, this seems like a very bad idea and now everyone has to do CSRF because of it? CORS doesn't prevent evil.com from sending a reqeust to bank.com, it only prevents reading the response, no? So again, what stops evil.com from sending a request to say transfer 1 BBBBillion dollars to bank.com and including a CSRF token it gets from visiting bank.com?
  - voxic11 2y ago
    > it only prevents reading the response, no? > So again, what stops evil.com from sending a request to say transfer 1 BBBBillion dollars to bank.com and including a CSRF token it gets from visiting bank.com? It can't read the response from bank.com so it can't read the CSRF token. The token is basically proving the caller is allowed to read bank.com with the user's credentials. Which is only possible if the caller lives on bank.com or a origin that bank.com has allowed via CORS.
  - chuckadams 2y ago
    > Right, this seems like a very bad idea and now everyone has to do CSRF because of it? Yep, that pretty much sums it up. CORS doesn't have to enter into it though: evil.com just has no way to read the CSRF token from bank.com, it's a one-time password that changes with every form (one hopes) and it's embedded in places that it can't access. It can send an arbitrary POST request, but no script originating from evil.com (or anywhere that is not bank.com) can get at the token it would need for that post to get past the CSRF prevention layer.
    - deleted 2y ago
      [deleted]
  - blincoln 2y ago
    CSRF tokens are only valid for a particular user, or session, or sometimes even a particular page load. If there's a way for evil.com to obtain a CSRF token that's valid for an arbitrary user, it's a vulnerability, just like if evil.com could obtain the user's session token, JWT, etc.
- Macha 2y ago
  Note that cookies now have the SameSite cookie option which should prevent this
- JimDabell 2y ago
  > > What stops a script on evil.com from going to bank.com... > CORS CORS does the exact opposite to what you think. Those types of cross-site requests are forbidden by default by the Same-Origin Policy (SOP) and CORS is designed so you can allow those requests where they would otherwise be forbidden. CORS is not a security barrier. Adding CORS removes a security barrier.
- Sohcahtoa82 2y ago
  > > What stops a script on evil.com from going to bank.com... > CORS Incorrect. It's SOP that prevents an evil.com script from going to bank.com It's CORS that allows evil.com. CORS is an insecurity feature that relaxes the SOP.
chuckadams 2y ago
> It seems like the problem is at the level of login information somehow crossing domain boundaries? The login information isn't so much crossing boundaries -- evil.com can't read your session cookie on bank.com -- but cookies that don't set a SameSite attribute allow anyone to send that information on your behalf, and effectively act as you in that request. Textbook example of a "confused deputy" attack. > What stops a script on evil.com from going to bank.com to get a CSRF token and then including that in their evil request? The token is either stored on the page that bank.com sends (for a html form) or was sent in a header and stored in local storage (for API clients). In neither case can evil.com read that information, due to cross-origin restrictions, and it changes with every form.
- alexashka 2y ago
  > In neither case can evil.com read that information What stops evil.com from having an API endpoint called evil.com/returnBankCSRFToken that goes to bank.com, scrapes token and returns it? CSRF tokens are just part of an html form - they are not hidden or obscured and thus scraping them is trivial. When I go to evil.com, it calls the endpoint, gets token and sends a request to bank.com using said token, thus bypassing CSRF?
  - hkpack 2y ago
    Nothing stops, but it will be a different CSRF token, which will not match to the one generated for the original page. Server keeps track of which CSRF token is given to which client using cookies (usually some form of SessionID), and stores it on the server somewhere. It is a very common pattern and all frameworks support it with the concept of "sessions" on the back end.
    - hansonkd 2y ago
      > stores it on the server somewhere you don't need to store anything on the server. cookies for that domain are sent with the request and it is enough for the server to check its cookie with the csrf request data. browsers would send the bank.com cookies with the bank.com request. It is security built into the browser which is why its so important to use secure browsers and secure cookies. If the malicious user convinces the user to use an insecure browser you can circumvent CSRF, but at that point there are probably other exploits you can do.

gavinsyancey 2y ago

When you logged in to bank.com, it set a cookie that your browser presents when it makes any request to bank.com, regardless of how it was initiated (i.e. it would still send the cookie on a cross-site XHR initiated by evil.com's JavaScript). > What stops a script on evil.com from going to bank.com... CORS

alexashka 2y ago
> it set a cookie that your browser presents when it makes any request to bank.com, regardless of how it was initiated Right, this seems like a very bad idea and now everyone has to do CSRF because of it? CORS doesn't prevent evil.com from sending a reqeust to bank.com, it only prevents reading the response, no? So again, what stops evil.com from sending a request to say transfer 1 BBBBillion dollars to bank.com and including a CSRF token it gets from visiting bank.com?
- voxic11 2y ago
  > it only prevents reading the response, no? > So again, what stops evil.com from sending a request to say transfer 1 BBBBillion dollars to bank.com and including a CSRF token it gets from visiting bank.com? It can't read the response from bank.com so it can't read the CSRF token. The token is basically proving the caller is allowed to read bank.com with the user's credentials. Which is only possible if the caller lives on bank.com or a origin that bank.com has allowed via CORS.
- chuckadams 2y ago
  > Right, this seems like a very bad idea and now everyone has to do CSRF because of it? Yep, that pretty much sums it up. CORS doesn't have to enter into it though: evil.com just has no way to read the CSRF token from bank.com, it's a one-time password that changes with every form (one hopes) and it's embedded in places that it can't access. It can send an arbitrary POST request, but no script originating from evil.com (or anywhere that is not bank.com) can get at the token it would need for that post to get past the CSRF prevention layer.
  - deleted 2y ago
    [deleted]
- blincoln 2y ago
  CSRF tokens are only valid for a particular user, or session, or sometimes even a particular page load. If there's a way for evil.com to obtain a CSRF token that's valid for an arbitrary user, it's a vulnerability, just like if evil.com could obtain the user's session token, JWT, etc.
Macha 2y ago
Note that cookies now have the SameSite cookie option which should prevent this
JimDabell 2y ago
> > What stops a script on evil.com from going to bank.com... > CORS CORS does the exact opposite to what you think. Those types of cross-site requests are forbidden by default by the Same-Origin Policy (SOP) and CORS is designed so you can allow those requests where they would otherwise be forbidden. CORS is not a security barrier. Adding CORS removes a security barrier.
Sohcahtoa82 2y ago
> > What stops a script on evil.com from going to bank.com... > CORS Incorrect. It's SOP that prevents an evil.com script from going to bank.com It's CORS that allows evil.com. CORS is an insecurity feature that relaxes the SOP.

chuckadams 2y ago

> It seems like the problem is at the level of login information somehow crossing domain boundaries? The login information isn't so much crossing boundaries -- evil.com can't read your session cookie on bank.com -- but cookies that don't set a SameSite attribute allow anyone to send that information on your behalf, and effectively act as you in that request. Textbook example of a "confused deputy" attack. > What stops a script on evil.com from going to bank.com to get a CSRF token and then including that in their evil request? The token is either stored on the page that bank.com sends (for a html form) or was sent in a header and stored in local storage (for API clients). In neither case can evil.com read that information, due to cross-origin restrictions, and it changes with every form.

alexashka 2y ago
> In neither case can evil.com read that information What stops evil.com from having an API endpoint called evil.com/returnBankCSRFToken that goes to bank.com, scrapes token and returns it? CSRF tokens are just part of an html form - they are not hidden or obscured and thus scraping them is trivial. When I go to evil.com, it calls the endpoint, gets token and sends a request to bank.com using said token, thus bypassing CSRF?
- hkpack 2y ago
  Nothing stops, but it will be a different CSRF token, which will not match to the one generated for the original page. Server keeps track of which CSRF token is given to which client using cookies (usually some form of SessionID), and stores it on the server somewhere. It is a very common pattern and all frameworks support it with the concept of "sessions" on the back end.
  - hansonkd 2y ago
    > stores it on the server somewhere you don't need to store anything on the server. cookies for that domain are sent with the request and it is enough for the server to check its cookie with the csrf request data. browsers would send the bank.com cookies with the bank.com request. It is security built into the browser which is why its so important to use secure browsers and secure cookies. If the malicious user convinces the user to use an insecure browser you can circumvent CSRF, but at that point there are probably other exploits you can do.