4 ms·

Also not a web dev, but if I'm remembering it correctly (someone please correct me if I'm wrong), the way I understood it was: Whenever your browser sends any

Also not a web dev, but if I'm remembering it correctly (someone please correct me if I'm wrong), the way I understood it was: Whenever your browser sends any request to any site, it sends the cookies(/other auth data) associated with that site along with it. In other words, cookies are fundamentally just associated with the receiver, not the sender. So the "solution" is for the receiver to block requests from the wrong sender, since otherwise any site could send authenticated requests to any random site. [Edit in response to comment below: I should've mentioned more here, but I understand what happened was browsers introduced the Same-Origin Policy to prevent this from happening, and introduced CORS as a dynamic bypass mechanism for that, which, unless you implement OPTIONS, can get you these half-baked insecure situations where requests still get sent and executed, but the client JS doesn't get to see the responses.] To me this whole mess is stupid because the premise shouldn't be true in the first place (why the heck should a cross-origin request send auth data? cookies etc. should be "contained" to whatever domains the original site restricted them to), but that's apparently The Way Things Are, and so here we are: browsers do something completely unexpected and insecure, and we blame devs for getting caught off-guard and not protecting against a security hole browsers introduce. (Yes, I have Opinions on this. Please tell me exactly where I'm wrong, because I suspect I might be, but I have yet to figure it out.)

dillonmckay 7y ago
So, it depends on the request type, GET vs POST and others. Before the client does the request for data, it does a preflight request via OPTIONS to determine what is allowable (is this domain allowed, this type of call). If it is allowed, it can send and request cookies on the requested domain in the current standard. However, this is not supported in older browsers, so the request will just work. In newer browsers, without the preflight check, the server still receives and replies to the request, but the reply is ‘ignored’ by the browser and throws an error.
- mehrdadn 7y ago
  I'm aware of OPTIONS but it still seems like the same exact stupid browser security hole (edit: or perhaps I should say HTTP protocol flaw?) being half-patched on the server side. Like, I'm saying that -- independent of the HTTP method -- there should be no communication of privileged information in the first place by default. If a website really wants other arbitrary websites to send e.g. a cookie along, then there should be a way to mark that cookie as such at the time that it is originally set, not having it checked post-facto. It sounds like the only reason this is done is backward-compatibility?
  - dillonmckay 7y ago
    Definitely not disagreeing. The server still sees the request, so the data can be exfiltrated. In terms of backwards compatibility, it is actually the opposite. Newer browsers will block stuff that worked in older versions.
  - tgsovlerkhgsel 7y ago
    You can mark a cookie as samesite: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#samesite-cookie-attribute https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... (as you mentioned, backwards compatibility requires that this is opt-in when the cookie is set, not opt-out)
    - mehrdadn 7y ago
      Oh wow, 2017. Finally...
pixelperfect 7y ago
I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy. The auth data would only be included if the server that the request is being sent to responds with an Access-Control-Allow-Origin header whose value matches the origin the request was made from.
- mehrdadn 7y ago
  I think we're agreeing? Like using CORS headers is a mechanism used to bypass SOP when needed, which was implemented because HTTP handles cookies in a stupid way and now nobody wants to change how that's done, right? Like neither CORS nor SOP should've been necessary in the first place had cookies explicitly included the allowed senders instead of just the receivers. (P.S. the way you phrased the request handling would violate causality, so I'm assuming you were referring to the OPTIONS check beforehand...)
- anaphor 7y ago
  > I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy Not necessarily true. You can have Javascript running on evil.com that submits a form to banking.com and it will send your session cookies for banking.com along with the request. It's just that evil.com can't read the response content.
  - pixelperfect 7y ago
    I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com. I'll admit I may be one of the developers that doesn't understand CORS...
    - anaphor 7y ago
      I think you could implement that with CORS + CSRF tokens (blocking all types of Cross-Origin requests) but the default behaviour is to allow Cross-Origin writes (e.g. with form submissions). See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Cross-origin_network_access https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... This is why we have CSRF tokens. So that you can effectively block Cross-Origin writes.

dillonmckay 7y ago

So, it depends on the request type, GET vs POST and others. Before the client does the request for data, it does a preflight request via OPTIONS to determine what is allowable (is this domain allowed, this type of call). If it is allowed, it can send and request cookies on the requested domain in the current standard. However, this is not supported in older browsers, so the request will just work. In newer browsers, without the preflight check, the server still receives and replies to the request, but the reply is ‘ignored’ by the browser and throws an error.

mehrdadn 7y ago
I'm aware of OPTIONS but it still seems like the same exact stupid browser security hole (edit: or perhaps I should say HTTP protocol flaw?) being half-patched on the server side. Like, I'm saying that -- independent of the HTTP method -- there should be no communication of privileged information in the first place by default. If a website really wants other arbitrary websites to send e.g. a cookie along, then there should be a way to mark that cookie as such at the time that it is originally set, not having it checked post-facto. It sounds like the only reason this is done is backward-compatibility?
- dillonmckay 7y ago
  Definitely not disagreeing. The server still sees the request, so the data can be exfiltrated. In terms of backwards compatibility, it is actually the opposite. Newer browsers will block stuff that worked in older versions.
- tgsovlerkhgsel 7y ago
  You can mark a cookie as samesite: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#samesite-cookie-attribute https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... (as you mentioned, backwards compatibility requires that this is opt-in when the cookie is set, not opt-out)
  - mehrdadn 7y ago
    Oh wow, 2017. Finally...

pixelperfect 7y ago

I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy. The auth data would only be included if the server that the request is being sent to responds with an Access-Control-Allow-Origin header whose value matches the origin the request was made from.

mehrdadn 7y ago
I think we're agreeing? Like using CORS headers is a mechanism used to bypass SOP when needed, which was implemented because HTTP handles cookies in a stupid way and now nobody wants to change how that's done, right? Like neither CORS nor SOP should've been necessary in the first place had cookies explicitly included the allowed senders instead of just the receivers. (P.S. the way you phrased the request handling would violate causality, so I'm assuming you were referring to the OPTIONS check beforehand...)
anaphor 7y ago
> I'm pretty sure you're incorrect - requests to sites different from the one you are currently on will not include auth data by default because of the same-origin policy Not necessarily true. You can have Javascript running on evil.com that submits a form to banking.com and it will send your session cookies for banking.com along with the request. It's just that evil.com can't read the response content.
- pixelperfect 7y ago
  I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com. I'll admit I may be one of the developers that doesn't understand CORS...
  - anaphor 7y ago
    I think you could implement that with CORS + CSRF tokens (blocking all types of Cross-Origin requests) but the default behaviour is to allow Cross-Origin writes (e.g. with form submissions). See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Cross-origin_network_access https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... This is why we have CSRF tokens. So that you can effectively block Cross-Origin writes.