5 ms·

I'm relatively new to the world of browser CORS concerns. But let me get this straight: > Such a configuration has to be carefully considered. Yet, putting rel

by dcow 6y ago

I'm relatively new to the world of browser CORS concerns. But let me get this straight: > Such a configuration has to be carefully considered. Yet, putting relaxed CORS headers is almost always safe. One rule of thumb is: if you open the URL in an incognito tab, and you are happy with the information you are exposing, then you can set a permissive (*) CORS policy on said URL. > A dangerous prospect of such configuration is when it comes to content served on private networks (i.e. behind firewall or VPN). When you are connected via a VPN, you have access to the files on the company’s network So the entire CORS dance exists because people thought VPNs were a good solution to protecting resources on the internet? That's mildly infuriating...

deleted 6y ago
[deleted]
lostcolony 6y ago
No. That's one potential risk, but hardly the only one. The entire CORS dance is to work around the pre-existing browser based security model. It was specifically to create a backwards compatible model that would enable requests across origins, without compromising the existing security model. This is a little overly simplified, but, consider how 'helpful' the browser is; when you make a request to a backend, any related cookie gets sent along with it. So, a danger realized early on was (by example), if someone was logged into their bank, and then accessed a malicious site, the malicious site could make a request to the bank to, say, transfer money. Because the bank used cookies for authentication, the transfer would be authorized and go through. VPN is a similar risk, but even authenticated resources might be available, depending on the type of authentication (and, certainly, unauthenticated ones are exposed). To prevent that, early on, they decided to block cross origin requests entirely. Well, almost; due to the nature of the web, GET requests had to be able to be made cross origin (it's why you can link to other websites/content), so they just prevented scripts from having access to the data. This was fine from a security standpoint, but it had a major usability issue. A lot of terrible workarounds were implemented (I'm looking at you, JSONP), with CORS being the official "this is how we'll allow you to, intentionally, relax this requirement, while still keeping the security decisions in place, and allow everything to be backwards compatible".
- dcow 6y ago
  I thought origin policies could be applied at the cookie level such that the browser would only send the relevant cookies to your bank if the request originated from active user navigation to bank.com or from content served by the response received thereafter: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...? That way instead of service X saying "only requests from these origins are allowed", bank.com is saying "these cookies are sensitive please restrict them to requests that happen when the user has actually navigated to our website". In the bank scenario you presented, does CORS provide any additional benefit beyond cookie-level access control policies? Is there another scenario I'm missing in general?
  - lostcolony 6y ago
    SameSite was created by Google in 2016, and required both adoption across browsers and backend changes to be secure (that is, reliance on SameSite being set for security would mean backends that don't set it are not secure; it is opt in). Preventing cross origin requests as a necessary security measure happened as part of the initial implementation of XmlHttpRequest back in the 90s. CORS was a working draft as early as 2006, implemented across browsers by 2013ish, accepted as a W3C recommendation in 2014, and was 'secure by default'; the only backend changes necessary were when you wanted to allow cross origin requests (that is, it is opt out).
    - deleted 6y ago
      [deleted]
  - colinclerk 6y ago
    The SameSite cookie policy doesn't offer fine-grained control like CORS. So, if you want to allowlist cookies for certain third-party origins but not all, CORS would be a better option. In practice, most sites want to prevent all cross-origin requests and SameSite is easier. And in more recent practice, Safari and Firefox are blocking third-party cookies by default, so it's pretty rare to see a setup leveraging CORS for fine-grained cookie access.
astockwell 6y ago
Sadly, many MANY people in high places still think VPNs are the best solution (and the only solution you need) to protecting resources.
icedchai 6y ago
The entire CORS dance exists because we're building applications on platform originally intended for public documents.
domenicd 6y ago
Kind of. As I explained in my sibling comment at https://news.ycombinator.com/item?id=26801359 https://news.ycombinator.com/item?id=26801359 , it really exists because people (e.g. intranet administrators) expose resources based on your network status or IP addresses. I think this is a bit more general than specifically VPNs. If it wasn't for that, then yeah, we could just strip cookies/client certs/etc. from cross-origin requests and they'd be safe.
yaur 6y ago
CORS is not that hard and never has been. The real problem is that bank.com keeps hiring developers that think CORS is an obstacle to be overcome instead of a feature that is providing value. As a result CORS keeps getting more complicated in order to break the workarounds of those who thought they got it right the first time while also breaking things for those that actually did.

by dcow 6y ago

deleted 6y ago

[deleted]

lostcolony 6y ago

No. That's one potential risk, but hardly the only one. The entire CORS dance is to work around the pre-existing browser based security model. It was specifically to create a backwards compatible model that would enable requests across origins, without compromising the existing security model. This is a little overly simplified, but, consider how 'helpful' the browser is; when you make a request to a backend, any related cookie gets sent along with it. So, a danger realized early on was (by example), if someone was logged into their bank, and then accessed a malicious site, the malicious site could make a request to the bank to, say, transfer money. Because the bank used cookies for authentication, the transfer would be authorized and go through. VPN is a similar risk, but even authenticated resources might be available, depending on the type of authentication (and, certainly, unauthenticated ones are exposed). To prevent that, early on, they decided to block cross origin requests entirely. Well, almost; due to the nature of the web, GET requests had to be able to be made cross origin (it's why you can link to other websites/content), so they just prevented scripts from having access to the data. This was fine from a security standpoint, but it had a major usability issue. A lot of terrible workarounds were implemented (I'm looking at you, JSONP), with CORS being the official "this is how we'll allow you to, intentionally, relax this requirement, while still keeping the security decisions in place, and allow everything to be backwards compatible".

dcow 6y ago
I thought origin policies could be applied at the cookie level such that the browser would only send the relevant cookies to your bank if the request originated from active user navigation to bank.com or from content served by the response received thereafter: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...? That way instead of service X saying "only requests from these origins are allowed", bank.com is saying "these cookies are sensitive please restrict them to requests that happen when the user has actually navigated to our website". In the bank scenario you presented, does CORS provide any additional benefit beyond cookie-level access control policies? Is there another scenario I'm missing in general?
- lostcolony 6y ago
  SameSite was created by Google in 2016, and required both adoption across browsers and backend changes to be secure (that is, reliance on SameSite being set for security would mean backends that don't set it are not secure; it is opt in). Preventing cross origin requests as a necessary security measure happened as part of the initial implementation of XmlHttpRequest back in the 90s. CORS was a working draft as early as 2006, implemented across browsers by 2013ish, accepted as a W3C recommendation in 2014, and was 'secure by default'; the only backend changes necessary were when you wanted to allow cross origin requests (that is, it is opt out).
  - deleted 6y ago
    [deleted]
- colinclerk 6y ago
  The SameSite cookie policy doesn't offer fine-grained control like CORS. So, if you want to allowlist cookies for certain third-party origins but not all, CORS would be a better option. In practice, most sites want to prevent all cross-origin requests and SameSite is easier. And in more recent practice, Safari and Firefox are blocking third-party cookies by default, so it's pretty rare to see a setup leveraging CORS for fine-grained cookie access.

astockwell 6y ago

Sadly, many MANY people in high places still think VPNs are the best solution (and the only solution you need) to protecting resources.

icedchai 6y ago

The entire CORS dance exists because we're building applications on platform originally intended for public documents.

domenicd 6y ago

Kind of. As I explained in my sibling comment at https://news.ycombinator.com/item?id=26801359 https://news.ycombinator.com/item?id=26801359 , it really exists because people (e.g. intranet administrators) expose resources based on your network status or IP addresses. I think this is a bit more general than specifically VPNs. If it wasn't for that, then yeah, we could just strip cookies/client certs/etc. from cross-origin requests and they'd be safe.

yaur 6y ago

CORS is not that hard and never has been. The real problem is that bank.com keeps hiring developers that think CORS is an obstacle to be overcome instead of a feature that is providing value. As a result CORS keeps getting more complicated in order to break the workarounds of those who thought they got it right the first time while also breaking things for those that actually did.