2

I know exactly how CORS is working, i know it's implemented on browsers, and i know it forbids XMLHTTPRequests to other origins unless the remote origin allows it using the response header Access-Control-Allow-Origin.

And of-course I heard it's because the "security reasons" that it's there.

The thing i don't get is how it's improving security.

So imagine we're in a browser and we have a malicious js file loaded in our page and it wants to send our local storage data or cookies to another origin (hacker origin). so the hacker simply set the "Access-Control-Allow-Origin" to * and he's good to go! so what CORS did exactly here?

Somewhere i read that CORS is there because of "intellectual property" and that makes sense somehow, so some remote servers don't want to answer to requests from other clients. that's ok.. . but for security reasons!? I don't get that part.

I would appreciate if anyone could help me with this.

behz4d
  • 1,819
  • 5
  • 35
  • 59
  • CORS doesn't protect your data if you allowed a malicious JS file to execute in your page. It protects your data (or more specifically, your user's session/auth data) if there is malicious JS in *any other page*, because *that page* is not allowed to read responses from your server. – Bergi Feb 28 '22 at 11:21
  • Protecting your page against including malicious JS files is the job of [Content Security Policies](https://en.wikipedia.org/wiki/Content_Security_Policy). – Bergi Feb 28 '22 at 11:23
  • what do you mean by `any other page`, you mean loading a js file from another origin in my page? ok then it doesn't have access to my cookies because it only can access to it's own domain cookies right? maybe local storage. yet again, imagine now it has access to my local storage data, then it can send them to his own server! so how CORS helped here? he set the policy to `*` in his own origin. what is it there that i'm missing? – behz4d Feb 28 '22 at 11:28
  • If it's loaded into your page, it also has access to your page's cookies, regardless of the origin of the code. But no, that's not what I was talking about, it's about JavaScript code on *other* pages, pages that you don't control, making requests to your server using the cookies of your users. And it's the [Same Origin Policy](https://en.wikipedia.org/wiki/Same-origin_policy) that provides security for those cases. CORS actually isn't improving security, it's a method to lift the SOP restrictions where you need to. – Bergi Feb 28 '22 at 11:33
  • if **http://example.com/file.js** is loaded in my page, then it only has access **example.com** cookies, am i right? and please define **other pages** – behz4d Feb 28 '22 at 11:37
  • No, if it's loaded in your page, it has access to your cookies via `document.cookie`, and not those of `example.com`. However in the GET request for loading the file, the browser will use the `example.com` cookies. But again, that's not what SOP and CORS are about. – Bergi Feb 28 '22 at 11:41
  • "Other pages" means pages from any other domain. Really anything. See https://en.wikipedia.org/wiki/Same-origin_policy#Read_access_to_sensitive_cross-origin_responses_via_reusable_authentication and https://en.wikipedia.org/wiki/Cross-site_request_forgery – Bergi Feb 28 '22 at 11:42
  • @Bergi then when my bank site uses jquery.js loaded from a CDN, the jquery.js has access to bank cookies!? isn't this weird? then why it's said that it's better to store for example JWT tokens in cookies and not local storage? since if a malicious script loaded from another origin is in our page, it can access the local storage but not the cookies (it can access cookies but for it's own domain only which is a CDN forexample).. . now i'm even more confused compared to before asking this question.. . a full answer that considers these questions is appreciated – behz4d Feb 28 '22 at 12:05
  • @behz4d Scripts can be loaded from other origins, but those scripts execute in the context of the origin that loads them. See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_network_access – jub0bs Feb 28 '22 at 13:26
  • @behz4d Yes, jQuery can access your cookies on your bank's domain. Which is precisely why a security-minded bank does not use an untrusted CDN but rather their own copy of the jQuery script, or they use CSP to verify the contents of the CDN-served script. "*why it's said that it's better to store for example JWT tokens in cookies and not local storage?*" - where is that said? No, if you allow a malicious script to execute on your page, you've already lost, regardless where and how you store your JWTs. But again, none of this has anything to do with CORS. – Bergi Feb 28 '22 at 13:32
  • @Bergi CSP? Did you mean SRI? – jub0bs Feb 28 '22 at 18:47
  • @jub0bs yes. Isn't that part of CSP? Maybe I confused them. – Bergi Feb 28 '22 at 18:49
  • @Bergi No, CSP and SRI are distinct. CSP did use to have a [`require-sri-for` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for), but it's now deprecated. – jub0bs Feb 28 '22 at 18:52
  • @behz4d Here's where you're correct: an HTTP-only cookie cannot be _directly_ accessed by malicious JS. HOWEVER, if malicious JS makes a request to `example.com`, the browser WILL send all cookies associated with `example.com` on the request. The browser WILL send all cookies associated with a domain on requests to that domain. To prevent this from being abused, browsers block cross-origin requests by default. This is the same-origin policy. Same-origin can be relaxed though. Your server can specify origins (other domains) which ARE allowed to make cross-origin requests to it. This is CORS. – josephsturm Jun 13 '23 at 20:39
  • 1
    @behz4d So for an example: you log into `mybank.com`. You now have a valid session token for `mybank.com` in your browser cookies. If you now go to `evil.com` and it fires off a malicious fetch request to `mybank.com/api/...`, that request *will contain your real, valid session token*. The same-origin policy says all requests to `mybank.com` will be blocked unless they're coming from `mybank.com`. If the devs of `mybank.com` want to allow `otherbank.com` to make requests, say for transfers, they can specify `otherbank.com` in the CORS header to allow that. `evil.com` is still blocked. – josephsturm Jun 13 '23 at 20:45

0 Answers0