3 ms·

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have

by chpmrc 7y ago

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

untog 7y ago
Browsers are ubiquitous, and they run third party code. That would be a deadly combination for anyone hoping to launch a DDOS attack if CORS protections didn't exist.
- chpmrc 7y ago
  The same could be said about operating systems. In fact when just replacing "Browsers" with "Operating systems" your sentence would still hold true.
  - untog 7y ago
    Not really. Third party code that you haven't installed does not run in an operating system at the click of a button. It does in the browser. By the logic you're outlining there's no reason to sandbox a browser at all, since it's no different to an operating system. Experience suggests that would not be wise.
jimmychangas 7y ago
The default cross-origin blocking behavior is useful for many things, such prevention of data exfiltration via XSS vulnerabilties. CORS is a way to relax this behavior.
why-el 7y ago
That's certainly true, you are making the leap of faith that your customers are running standard compliant browsers, which, all considered, is true. All the techniques you mention require you to break either the customers or some element along the network chain to the server, and once you do, well, CORS is the least of your problems.
- jrochkind1 7y ago
  Yes. CORS is not so much a protection of your site against malicious user-agents; It is a protection of your site's users, using good non-malicious browsers, against malicious other JS on the web. I think this is one of the most basic misunderstood things about CORS. Once you understand that, you can start actually trying to understand the threat model... which is still pretty confusing, to me anyway. But until you are there, you haven't even started.
  - chpmrc 7y ago
    If a native app can request any resource why shouldn't a web app be able to do that too? Does it matter whether that app runs in my browser, Electron (which can easily bypass CORS policies) or whatever other runtime? If it does then CORS restrictions should be put in place at the OS level, if it doesn't they should be removed altogether. There are a ton of other ways to make sure you don't "give your stuff" to unauthorized parties: authentication, CRSF tokens, hash validation. Seriously, if it gets to the point of having to write "{Class of professionals} don't understand {Obscure restriction that doesn't make much sense nowadays}" it's likely not a security issue anymore, it's a UX issue (with the developers being the users). At the very least prompt the user to (dis)allow CORS when a request is being made, similarly to how the user is warned when running an unsigned executable on macOS.
    - jrochkind1 7y ago
      A web browser is different than a native app, because simply clicking a link can execute code from an untrusted party. First of all, when you are using a web browser, if it wasn't for cross-browser request restrictions, code executing on one site (or web app) would be able to _use credentials stored in cookies_ by another site altogether. Because all these web apps exist in the same browser context. Native apps are all separate, code running in an Native App A can't say "make a request to facebook using the credentials the user already logged into in the facebook app." But Web App A could do exactly that with the credentials the user logged into on facebook.com -- if it wasn't for cross-browser request restrictions. Which then CORS let some sites carefully opt out of. Secondly, when you download an app, you are trusting the developers of that app. You navigate the web, you are trusting every single site you visit (to also not have their own code injection or other vulnerabilities to which web pages/apps are particularly vulnerable to), and most users have no idea what sites they are visiting, they are just clicking links. What we really need a more clear explanation of the CORS threat model, with examples. I think we'd all be more clear about what it's for and why we need it if we understood it better. It is definitely a developer UX issue, but it is sadly one that is baked into the web for legacy reasons.
chpmrc 7y ago
Even Cordova (which basically runs a web view on mobile) has a plugin to bypass CORS (https://hackernoon.com/a-practical-solution-for-cors-cross-origin-resource-sharing-issues-in-ionic-3-and-cordova-2112fc282664 https://hackernoon.com/a-practical-solution-for-cors-cross-o...). Are we entirely sure that the benefits of disallowing CORS by default outweigh the annoyances? Is there any study on this?
- squiggleblaz 7y ago
  The point of CORB (i.e. cross origin request blocking i.e. what browsers are doing i.e. what CORS relaxes) is effectively to stop authenticated requests from going from a browser with multiple authentications to a protected server on the basis of a request produced by third party. In other words, it's to stop the developer of fakegoogle.com using your web browser to access google.com as if they are you. Therefore, if you've written an app which will only ever contain cookies and authentications you've permitted, and only ever access servers that you've specified, then yeah, sure, CORB is irrelevant and you can safely ignore them. You and the malicious coder can both write code that runs on Android or iOS safe in the knowledge that there's an absolute sandbox between them - nothing the malicious coder ever does will ever leak your user's secrets to your server. Likewise, if you're a malicious coder and you convince the user to give you their legit google.com secrets, you can safely send them wherever you want. If you're writing a web browser equivalent app, that will run arbitrary code from untrusted third parties and store and release private or secret information, CORB makes sense and you should pay attention to the CORS headers. CORB is solving a problem inherent in web browsers - they run untrusted code and code can cause your secrets to go to your server. It is annoying to you as a web app writer in the same way that locked doors are annoying to plumbers. It would be so much easier for the plumber if they could just come around to my house whenever it's convenient. And it doesn't solve any problem the plumber has (if some random steals all your gold, how is that the plumbers' problem?). Inside your house you don't lock every door. But you do lock the doors that separate trusted and untrusted people, and no amount of difficulty to plumbers will change that.
Thorrez 7y ago
Are you saying that because a native app on my system can do something, a website should be able to do it too? A native app on my system can delete all my files without asking me. I don't want a website to be able to do that.

by chpmrc 7y ago

untog 7y ago

Browsers are ubiquitous, and they run third party code. That would be a deadly combination for anyone hoping to launch a DDOS attack if CORS protections didn't exist.

chpmrc 7y ago
The same could be said about operating systems. In fact when just replacing "Browsers" with "Operating systems" your sentence would still hold true.
- untog 7y ago
  Not really. Third party code that you haven't installed does not run in an operating system at the click of a button. It does in the browser. By the logic you're outlining there's no reason to sandbox a browser at all, since it's no different to an operating system. Experience suggests that would not be wise.

jimmychangas 7y ago

The default cross-origin blocking behavior is useful for many things, such prevention of data exfiltration via XSS vulnerabilties. CORS is a way to relax this behavior.

why-el 7y ago

That's certainly true, you are making the leap of faith that your customers are running standard compliant browsers, which, all considered, is true. All the techniques you mention require you to break either the customers or some element along the network chain to the server, and once you do, well, CORS is the least of your problems.

jrochkind1 7y ago
Yes. CORS is not so much a protection of your site against malicious user-agents; It is a protection of your site's users, using good non-malicious browsers, against malicious other JS on the web. I think this is one of the most basic misunderstood things about CORS. Once you understand that, you can start actually trying to understand the threat model... which is still pretty confusing, to me anyway. But until you are there, you haven't even started.
- chpmrc 7y ago
  If a native app can request any resource why shouldn't a web app be able to do that too? Does it matter whether that app runs in my browser, Electron (which can easily bypass CORS policies) or whatever other runtime? If it does then CORS restrictions should be put in place at the OS level, if it doesn't they should be removed altogether. There are a ton of other ways to make sure you don't "give your stuff" to unauthorized parties: authentication, CRSF tokens, hash validation. Seriously, if it gets to the point of having to write "{Class of professionals} don't understand {Obscure restriction that doesn't make much sense nowadays}" it's likely not a security issue anymore, it's a UX issue (with the developers being the users). At the very least prompt the user to (dis)allow CORS when a request is being made, similarly to how the user is warned when running an unsigned executable on macOS.
  - jrochkind1 7y ago
    A web browser is different than a native app, because simply clicking a link can execute code from an untrusted party. First of all, when you are using a web browser, if it wasn't for cross-browser request restrictions, code executing on one site (or web app) would be able to _use credentials stored in cookies_ by another site altogether. Because all these web apps exist in the same browser context. Native apps are all separate, code running in an Native App A can't say "make a request to facebook using the credentials the user already logged into in the facebook app." But Web App A could do exactly that with the credentials the user logged into on facebook.com -- if it wasn't for cross-browser request restrictions. Which then CORS let some sites carefully opt out of. Secondly, when you download an app, you are trusting the developers of that app. You navigate the web, you are trusting every single site you visit (to also not have their own code injection or other vulnerabilities to which web pages/apps are particularly vulnerable to), and most users have no idea what sites they are visiting, they are just clicking links. What we really need a more clear explanation of the CORS threat model, with examples. I think we'd all be more clear about what it's for and why we need it if we understood it better. It is definitely a developer UX issue, but it is sadly one that is baked into the web for legacy reasons.

chpmrc 7y ago

Even Cordova (which basically runs a web view on mobile) has a plugin to bypass CORS (https://hackernoon.com/a-practical-solution-for-cors-cross-origin-resource-sharing-issues-in-ionic-3-and-cordova-2112fc282664 https://hackernoon.com/a-practical-solution-for-cors-cross-o...). Are we entirely sure that the benefits of disallowing CORS by default outweigh the annoyances? Is there any study on this?

squiggleblaz 7y ago
The point of CORB (i.e. cross origin request blocking i.e. what browsers are doing i.e. what CORS relaxes) is effectively to stop authenticated requests from going from a browser with multiple authentications to a protected server on the basis of a request produced by third party. In other words, it's to stop the developer of fakegoogle.com using your web browser to access google.com as if they are you. Therefore, if you've written an app which will only ever contain cookies and authentications you've permitted, and only ever access servers that you've specified, then yeah, sure, CORB is irrelevant and you can safely ignore them. You and the malicious coder can both write code that runs on Android or iOS safe in the knowledge that there's an absolute sandbox between them - nothing the malicious coder ever does will ever leak your user's secrets to your server. Likewise, if you're a malicious coder and you convince the user to give you their legit google.com secrets, you can safely send them wherever you want. If you're writing a web browser equivalent app, that will run arbitrary code from untrusted third parties and store and release private or secret information, CORB makes sense and you should pay attention to the CORS headers. CORB is solving a problem inherent in web browsers - they run untrusted code and code can cause your secrets to go to your server. It is annoying to you as a web app writer in the same way that locked doors are annoying to plumbers. It would be so much easier for the plumber if they could just come around to my house whenever it's convenient. And it doesn't solve any problem the plumber has (if some random steals all your gold, how is that the plumbers' problem?). Inside your house you don't lock every door. But you do lock the doors that separate trusted and untrusted people, and no amount of difficulty to plumbers will change that.

Thorrez 7y ago

Are you saying that because a native app on my system can do something, a website should be able to do it too? A native app on my system can delete all my files without asking me. I don't want a website to be able to do that.