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

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

31–40 of 366 posts

Re: Developers don't understand CORS

#31

Post by zenexer »

The author suggests that using CORS to allow https://zoom.us with http://localhost:19421 is possible. This is factually incorrect. Mixed content policies prevent the http: origin from communicating with the https: origin.

"For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost."

That last sentence is incorrect – Chrome does respect CORS headers for localhost webservers.

It's only partially incorrect. In most cases, CORS will not work with localhost, at least without a self-signed certificate trusted by the browser.

Re: Developers don't understand CORS

#32

Post by davidw »

leowoo91 wrote: post #26
csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

As a motivation to use: To prevent other sites using your resources, causing you an extra bandwith cost.

Back in the day, we used to use some Apache redirect magic to redirect to, say, an image of our choosing when the Referrer header was wrong. I had a relatively polite 'hey, you can see this image here:' message. Other people redirected to less friendly things.

Re: Developers don't understand CORS

#33

Post by modethirteen »

mehrdadn wrote: post #7
jonstaab wrote: post #2

Totally agree. Something about CORS and the resources out there makes newcomers think that it's something the client has to do differently. I thought this when first doing cross-origin stuff, and thought it was just me until my dad (programmer for 30 years) got stuck on it the exact same way. Also, the author makes a good point that `Access-Control-Allow-Origin: *` is pretty dangerous. I hadn't really worried about i…

Could you give a realistic example where it wouldn't lead you to have a bigger problem on your hands? I think that'd be extremely helpful.

The company I work for provides embeddable JavaScript "web widgets". Our customers are companies, and their customers are consumers (we are business to business to consumer company). We host somewhat personal data specific to those consumers, and as such, the data should only be accessible by those consumers.

So, we provide the data API that these web widgets communicate with, and the web widgets themselves can be embedded on our customers' own websites (some-company.com). However, the customer can decide exactly which hostnames can embed the widget (through a control panel we provide), and these hostnames ultimately become the `Access-Control-Allow-Origin` value we provide with every API response. Perhaps they want it on foo.some-company.com or bar.some-company.com -- it's really up to our customer where they want these widgets to be embedded.

By doing this, the customer knows that no other website can host these widgets, thus exposing their consumers' data to a phishing attack as I outline here: https://news.ycombinator.com/item?id=20405169

Re: Developers don't understand CORS

#34

Post by dillonmckay »

mehrdadn wrote: post #25
dillonmckay wrote: post #17

Earlier quoted context omitted.

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,…

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…

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.

Re: Developers don't understand CORS

#35

Post by modethirteen »

stefan_ wrote: post #29
anaphor wrote: post #14

That is because CORS is a kludge to work around the fact that we decided to use session cookies "because developers understand it easily" instead of just re-doing everything. See https://w3c.github.io/webappsec-cors-for-developers/#cors > Enter Cross-Origin Resource Sharing. The challenge when designing CORS was how to enable web applications to request and receive more cross-origin permissions, without exposing exis…

Wrong conclusion. The kludge is making cross origin requests in the first place.

Cross origin requests are legitimate in some use cases. I outline one here: https://news.ycombinator.com/item?id=20405275

TL;DR Hosting cross domain web widgets or customer engagement experiences like chat windows, etc

Re: Developers don't understand CORS

#36

Post by mehrdadn »

pixelperfect wrote: post #23
mehrdadn wrote: post #11

Earlier quoted context omitted.

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 wr…

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.

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...)

Re: Developers don't understand CORS

#37

Post by jandrese »

stefan_ wrote: post #29
anaphor wrote: post #14

That is because CORS is a kludge to work around the fact that we decided to use session cookies "because developers understand it easily" instead of just re-doing everything. See https://w3c.github.io/webappsec-cors-for-developers/#cors > Enter Cross-Origin Resource Sharing. The challenge when designing CORS was how to enable web applications to request and receive more cross-origin permissions, without exposing exis…

Wrong conclusion. The kludge is making cross origin requests in the first place.

What's the alternative? The webserver requests the third party resources on your behalf and repackages them into its own response?

Re: Developers don't understand CORS

#38

Post by leesec »

EGreg wrote: post #24

Seriously wondering! Why is Zoom worth $2B and companies are paying per minute plans to host meetings when you can now host your own videoconferencing software easily on your own website or app or intranet using WebRTC, branded, with your own experience, widgets, and it can all be open source? All you need to pay for are dumb TURN servers eg from twilio. Plus it would be far more secure. For example we built https://…

This reads so much like the infamous dropbox comment.

Re: Developers don't understand CORS

#39

Post by dillonmckay »

chrshawkes wrote: post #16
phkahler wrote: post #6

Not a web dev. Can anyone tell me what CORS is ultimately used for? Not the literal technical details, the higher level what does it enable sites to do? And is that for them or their visiters?

In a nutshell, because of CORS, one domain cannot communicate with another domain. The domain being communicated with, will automatically reject requests, unless the server is setup to specifically allow the request to go through via setting CORS headers to white list specific domains or all domains (bad idea).

So, that is not my understanding, but I could definitely be wrong.

So, the one domain will attempt to communicate, the other domain will receive the request and return a response.

If the client doesn’t ‘like’ the response, it will error.

Re: Developers don't understand CORS

#40

Post by therein »

edejong wrote: post #28
csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

I read extensive parts of the CORS specification and it is indeed teflon (and just as toxic as teflon as well). The spec is full of exceptions and leaves many choices to the browser vendors. To truly understand CORS, you have to fundamentally understand 'the origin' as a security and execution context. Sharing means that content normally intended for another origin is shared with the initial origin. Perhaps that is b…

> In that case, I propose to read more of the spec.

Ingest more teflon when in doubt about its toxicity.

Post reply on HN