Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do You Really Know CORS?

performantcode.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Do You Really Know CORS?

#101

Post by guscost »

matt4077 wrote: post #81
guscost wrote: post #37

CORS is a technical subsidy granted to (sloppy) users of cookie authentication. I’ve never worked on a project where it was anything other than an annoying hoop to jump through.

When has "subsidy" become the go-to narrative to argue against any sort of deference to real-world usage? You could just as easily frame CORS as "antibiotics for the people who dared to leave their house". (There's also a no-true-scotsman fallacy going on in your argument)

More like "mandatory medical testing at the airport because some people don't vaccinate" from my perspective.

It's a "subsidy" because we all have to spend time on it, even though lots of people don't receive any benefit from it. It's not intolerable, the Web is based on community standards and responds to community needs, and I'm fine with that. But I'm always on the losing end of this one so I'm going to say so.

Re: Do You Really Know CORS?

#102

Post by paulddraper »

notyourday wrote: post #28
paulddraper wrote: post #8

Earlier quoted context omitted.

CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS p…

I don't misunderstand.

My beef with CORS is that I have to encoded the validation logic into its HTTP headers.

But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?

Re: Do You Really Know CORS?

#103

Post by zackmorris »

zackmorris wrote: post #35
JepZ wrote: post #33

I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins? In my opinion, it would have been much better to improve the browsers to not include coo…

Ya I generally think CORS is a waste of time. It would have been better to provide a hash of the file we're linking to and trust that rather than where it came from. Which is precisely what Subresource Integrity (SRI) does: https://en.wikipedia.org/wiki/Subresource_Integrity Sadly even though this is an obvious concept and trivial to implement, it took them over 20 years since the web came out to get it in most brows…

After sleeping on it, I realized that my comment was a bit too critical and also missing some context. I didn't mean to be as negative at CORS as I came across, I was more disappointed that something like SRI hasn't been part of the web from the start. Some background:

https://en.wikipedia.org/wiki/Content-addressable_memory

https://en.wikipedia.org/wiki/Distributed_hash_table

https://en.wikipedia.org/wiki/Merkle_tree

If we had something like SRI from the start, we could have linked to resources by their hash instead of their URL (more like how IPFS works). There's a name for this concept that eludes me, and also a great video explaining its potential but also difficulties when it comes to security and HTTPS. The short of it is that if we had routers that accepted hashes as well as URLs, then we could ask for a list of all data matching a given hash and download that file (or its pieces) from the closest cache(s). So instead of linking to jQuery at https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.mi... we could just ask the router for the file with SHA2 hash 160a426ff2894252cd7cebbdd6d6b7da8fcd319c65b70468f10b6690c45d02ef and it would return its contents regardless of where it came from, including the browser's own cache if it already had that file (I just used https://hash.online-convert.com/sha256-generator but there would be a better standard for this).

Anyway, hope this helps and sorry for any confusion.

Re: Do You Really Know CORS?

#104

Post by sbergot »

Thu27Sep wrote: post #87

One idea that the article doesn't convey well, in my opinion, is that the Same-Origin Policy only prevents the browser from reading the response from an HTTP server to third-party host, but it doesn't prevent the request from being issued in a first place. The CORS headers are merely a way for the server to indicate to the browser whether it is allowed to read the response of not, but it doesn't protect the server fr…

This is not entirely true. The preflight's role is exactly to prevent a post request to be sent to the server. There is no preflight only in particular cases.

Re: Do You Really Know CORS?

#105

Post by sbergot »

int0x80 wrote: post #100
paulddraper wrote: post #8

Earlier quoted context omitted.

CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.

Exaclty. This is a big concern for me. The server is really telling the browser what to do. But the browser can ignore it. It is quite a hacky an inellegant model. Very broken.

CORS are about browser security. A browser can have terrible security in lots of ways (allowing JavaScript to access http only cookies, etc). In this case you have a bad browser and you should not use it.

But you can still use IE, edge, chrome and Safari and trust that they implement CORS and most other basic security features correctly.

Re: Do You Really Know CORS?

#106

Post by sbergot »

johncolanduoni wrote: post #44
icebraining wrote: post #12

Earlier quoted context omitted.

Same here... from what I can tell, only the browser has reliable information about what's happening. How could the server know code from another domain is making the requests? And if anything, the web is more secure - desktop native applications can usually access each other's data and do malicious requests to remote servers using stolen credentials just fine.

Via the Origin header, just like the preflight requests use. The server is ultimately the one telling the browser what the rules are already. The reason a preflight is needed is so that there is effectively a default deny policy, since both historically and even today you can’t assume all APIs that accept authentication tokens from the browser take into account any kind of cross origin access. Even still, a lot of pe…

You are talking about the Origin header set by the browser that you don't trust?

Re: Do You Really Know CORS?

#107

Post by sbergot »

paulddraper wrote: post #15
ravenstine wrote: post #10

Earlier quoted context omitted.

> rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

Then it means that a service is vulnerable by default unless it implements the list of allowed origins. With CORS if there are no headers then it means no authorization.

Re: Do You Really Know CORS?

#108

Post by sbergot »

paulddraper wrote: post #102
notyourday wrote: post #28

Earlier quoted context omitted.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS p…

I don't misunderstand. My beef with CORS is that I have to encoded the validation logic into its HTTP headers. But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?

Surely you can implement your security rules this way. But for most people CORS are a cheaper way to enable cross origin requests. And clueless people are stuck with same origin policy which secure by default.

Re: Do You Really Know CORS?

#109

Post by johncolanduoni »

sbergot wrote: post #106
johncolanduoni wrote: post #44

Earlier quoted context omitted.

Via the Origin header, just like the preflight requests use. The server is ultimately the one telling the browser what the rules are already. The reason a preflight is needed is so that there is effectively a default deny policy, since both historically and even today you can’t assume all APIs that accept authentication tokens from the browser take into account any kind of cross origin access. Even still, a lot of pe…

You are talking about the Origin header set by the browser that you don't trust?

The whole point of CORS is that you trust the browser to do the preflight requests and obey them, otherwise it doesn’t do anything. If you have access to the credentials (which the browser does) and the ability to send whatever HTTP requests you want, you can bypass CORS entirely.

Re: Do You Really Know CORS?

#110

Post by paulddraper »

Ajedi32 wrote: post #51
paulddraper wrote: post #8

Earlier quoted context omitted.

CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. I disagree. The current model where the server has to opt-in to cross origin access by explicitly sending an Access-Control-Allow-Origin header is secure-by-default, whereas a model relying on the server to enforce access wo…

It's already insecure-unless-the-server-checks-the-cookie-header.
Post reply on HN