4 ms·

There's something that continues to confuse me about CSRF protection. What's to stop an attacker, let's call her Eve, from going to goodsite.com, getting a CSR

There's something that continues to confuse me about CSRF protection. What's to stop an attacker, let's call her Eve, from going to goodsite.com, getting a CSRF token, putting it on badsite.com, and duping Alice into submitting a request to goodsite.com from badsite.com?

bastawhiz 2y ago
The csrf token is ideally tied to your session. If it's anonymous, Eve didn't need Alice to visit a page in the first place. If it's tied to a session, Eve can't create a working token for Alice.
- smagin 2y ago
  yup. You didn't imply it but just in case -- this token shouldn't be the same as session token. Session tokens should be `HttpOnly`, so that we don't even expose it to javascript
  - blincoln 2y ago
    The HttpOnly flag isn't really practical in modern web apps where so much logic runs in JS in the browser and makes requests to APIs. It's a leftover from an earlier era of web app architecture. If it can be enabled without breaking something, sure, its a good idea, but unless your app is 2000s-era ASP.NET code or CGI script, preventing browser-side JS from accessing the session token will probably break something.
    - Macha 2y ago
      Right, but if you're doing a SPA, your SPA makes the login call and stores a copy of the session token in local storage, which unlike a cookie isn't automatically sent on any request, never mind cross-origin ones. Doesn't prevent against XSS of course, but then that's what CSP is for.
    - bastawhiz 2y ago
      It's only necessary to store the login token if your backend is on a different origin than your SPA is served from. It's not especially hard to avoid this.
    - smagin 2y ago
      You shouldn't need your session token in JS, you can specify your fetch requests to include cookies, and you can setup CORS to allow that.
theogravity 2y ago
The CSRF token is usually stored in a cookie. I guess one could try stealing the cookie assuming the CSRF token hasn't been consumed. But if one's cookie happens to be stolen it can be assumed they already have access to your session in general anyways making CSRF moot.
preinheimer 2y ago
Traditionally csrf tokens had two parts: something in a cookie(/server side data store that used a cookie as the id), and something in a form element on the page. So while an attacker could trick your browser to making a request to get the cookie, and trick your browser into submitting arbitrary form data, they couldn’t get the csrf tokens to match.

bastawhiz 2y ago

The csrf token is ideally tied to your session. If it's anonymous, Eve didn't need Alice to visit a page in the first place. If it's tied to a session, Eve can't create a working token for Alice.

smagin 2y ago
yup. You didn't imply it but just in case -- this token shouldn't be the same as session token. Session tokens should be `HttpOnly`, so that we don't even expose it to javascript
- blincoln 2y ago
  The HttpOnly flag isn't really practical in modern web apps where so much logic runs in JS in the browser and makes requests to APIs. It's a leftover from an earlier era of web app architecture. If it can be enabled without breaking something, sure, its a good idea, but unless your app is 2000s-era ASP.NET code or CGI script, preventing browser-side JS from accessing the session token will probably break something.
  - Macha 2y ago
    Right, but if you're doing a SPA, your SPA makes the login call and stores a copy of the session token in local storage, which unlike a cookie isn't automatically sent on any request, never mind cross-origin ones. Doesn't prevent against XSS of course, but then that's what CSP is for.
  - bastawhiz 2y ago
    It's only necessary to store the login token if your backend is on a different origin than your SPA is served from. It's not especially hard to avoid this.
  - smagin 2y ago
    You shouldn't need your session token in JS, you can specify your fetch requests to include cookies, and you can setup CORS to allow that.

theogravity 2y ago

The CSRF token is usually stored in a cookie. I guess one could try stealing the cookie assuming the CSRF token hasn't been consumed. But if one's cookie happens to be stolen it can be assumed they already have access to your session in general anyways making CSRF moot.

preinheimer 2y ago

Traditionally csrf tokens had two parts: something in a cookie(/server side data store that used a cookie as the id), and something in a form element on the page. So while an attacker could trick your browser to making a request to get the cookie, and trick your browser into submitting arbitrary form data, they couldn’t get the csrf tokens to match.