1

I realise this is a newbie question but when it comes to this im clearly that.

On a browser, assuming one received a cookie from site A. Then a different site B makes a call to site A through it's javascript (lets leave redirects/clicks aside for now).

Does that call also carry the cookies stored in the browser for site A or is it that cookies are only sent through the appropriate domain context?

Im trying to better understand CSRF and evaluate if what im describing is a real scenario. For redirects such as facebook.com/DELETE_EVERYTHING where GET requests aren't idempotent I understand not much can be done. But I'm trying to see what other cases CSRF covers and how a POST can happen through CSRF.

If what I'm describing is valid then I understand how a CSRF token might help but in that case, why is this allowed in the first place?

If not, how can a CSRF POST happen?

  • They are sent through that context. Cookies have domain field and since you are sending request to that site they will be send too. Thats why tokens are helpful to prevent csrf If you dont provide them or you provide bad one it will get discarded – Tryna Learn Somethin Jan 15 at 23:08
2

In general, a browser sends all the cookies it has for site A whenever it makes a request to site A.

It doesn't usually matter where the request originated. There are two cases where it does, though:

  • JavaScript-initiated requests (XMLHttpRequest or fetch) will send cookies by default for same-origin requests, but not by default for cross-origin requests. You can specify that you want them sent for cross-origin, though.
  • The new samesite flag on cookies will restrict situations where they are sent via cross-origin requests. However, not all browsers support it yet, there are cases where it will break things, and unless in "strict" mode it will still send cookies on top-level navigation (such as when a link is clicked or window.location.href is set), which could exploit sites vulnerable to GET-based CSRF.

It also can matter whether you're sending the request over HTTP or HTTPS - cookies with the Secure flag will only go over HTTPS - but in general anything on a secure site should require HTTPS anyhow so that's where the attacker would direct their CSRF attack.


In other words:

On a browser, assuming one received a cookie from site A. Then a different site B makes a call to site A through it's javascript ( lets leave redirects/clicks aside for now ).

Does that call also carry the cookies stored in the browser for site A or is it that cookies are only sent through the appropriate domain context?

Yes, every call to request A will have the cookies for site A, regardless of where the request is coming from (aside from the caveats above).


As for POST requests, there's a few ways for that to happen. I already mentioned CORS (cross-origin) requests using XHR or Fetch APIs, where you need to specify "yes, with the credentials" but if you do that, cookies will be sent (assuming you use a "normal" content type and verb, and no custom headers; otherwise it'll trigger a CORS pre-flight checking whether to send the real request). You can also just have an HTML form - which could be entirely invisible, embedded in an iframe so it doesn't even navigate the top-level page when it gets submitted - that is submitted automatically by JavaScript. Forms can specify arbitrary destinations and actions, so it is entirely possible to send a cross-origin POST with one, and it will include cookies (subject only the the restrictions above around stuff like samesite or secure).

  • Thank you,bmvery comprehensive.Im just surprised samesite isnt there by default. Am i missing a usecase here? – Return-1 Jan 16 at 6:01
  • 1
    @Return-1 Well, in strict mode samesite would break things like "share on Facebook" because when you click the link, you'd be navigating across sites and so your browser wouldn't send your Facebook cookies and Facebook would think you aren't signed in. If samesite was used in its "lax" mode, that would be okay (for GET requests using top-level navigation) but it would still break POST requests submitted across origins. There's definitely an argument that the web should have been designed with a "cross-site" flag on cookies instead, but it's 25 years late for that. – CBHacking Jan 19 at 5:40
  • Chuckled at the last remark. Yeah was curious what the use cases for it were as if there were none , no backwards compatibility would break by banning it. Im not sure how share with facebook happens but I would imagine you just redirect to facebook with some url params and then everything happens on the context of facebook.com. This way nothing is posted from the original page. Any real scenarios where POSTing with cookies from cross origin is actually used today? Because if not, no backwards compat is breaking and therefore banning could be a thing?I mean why keep it? Thanks so much. – Return-1 Jan 20 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.