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

51–60 of 366 posts

Re: Developers don't understand CORS

#51

Post by [deleted] »

chrisfosterelli wrote: post #41
zenexer wrote: post #31

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

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect. If for some re…

[deleted]

Re: Developers don't understand CORS

#52

Post by MrStonedOne »

The number one issue with CORS I've found is that merely defining it undoes alot of defaults and most of the top searches on the subject of how to do x in CORS doesn't explain what those defaults are. So you get devs breaking things trying to whitelist something not normally allowed then deciding to cast a wide net to fix those things.

The CORS standard needs to be radically redefined from the ground up with developer ease of use as part of the consideration.

Re: Developers don't understand CORS

#53

Post by icebraining »

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.

On the contrary: CORS is what enables other sites to use your resources (in a way allowed by your policy). It was created because, by default, browsers don't let you do that.

Re: Developers don't understand CORS

#54

Post by pixelperfect »

anaphor wrote: post #47
pixelperfect wrote: post #23

Earlier quoted context omitted.

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'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 Not necessarily true. You can have Javascript running on evil.com that submits a form to banking.com and it will send your session cookies for banking.com along with the request. It's just that evil.com can't read the response content.

I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com.

I'll admit I may be one of the developers that doesn't understand CORS...

Re: Developers don't understand CORS

#55

Post by edejong »

chrisfosterelli wrote: post #44
edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is allowed. If for some reason that doesn't work for yo…

I see it is fixed now. I thought up this work-around back in 2014, when NPAPI was phased out. Spotify and another large player came up with similar solutions.

Re: Developers don't understand CORS

#56

Post by rezonant »

vbezhenar wrote: post #48
edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Installing trust store certificates for these purposes is asking for trouble. Sure, if the private key is unique per installation it theoretically should be fine, but in reality it can be hard to gather enough entropy to be satisfiably unpredictable, and it's very easy to get this wrong. It's worth noting that there isn't a solid way to limit your CA certificate in the trust-store to the domains you intend to use it with https://security.stackexchange.com/questions/31376/can-i-res...

Re: Developers don't understand CORS

#57

Post by edejong »

vbezhenar wrote: post #48
edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Sorry, I might initially have caused this mess, thinking browsers would fix it sooner than later.

Re: Developers don't understand CORS

#58

Post by badamp »

edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

> You simply cannot call 'http://localhost' from a https domain.

That’s simply wrong. You have outdated information. Unless you don’t consider Firefox, Chrome, IE, and Edge to matter. https://chromium.googlesource.com/chromium/src.git/+/130ee68...

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

Safari still has an open issue I think. But that’s no surprise since Apple has demonstrated they’re suckitude at software security and development in general.

Re: Developers don't understand CORS

#59

Post by chrisfosterelli »

edejong wrote: post #55
chrisfosterelli wrote: post #44

Earlier quoted context omitted.

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is allowed. If for some reason that doesn't work for yo…

I see it is fixed now. I thought up this work-around back in 2014, when NPAPI was phased out. Spotify and another large player came up with similar solutions.

Totally. I do get the constraints and I imagine Zoom had similar thinking here. The image approach, although hacky, can even be secure as-is if they need it for backward-compatibility but it needs to check the headers and not honour requests with the wrong value.

Re: Developers don't understand CORS

#60

Post by anaphor »

pixelperfect wrote: post #54
anaphor wrote: post #47

Earlier quoted context omitted.

> 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 Not necessarily true. You can have Javascript running on evil.com that submits a form to banking.com and it will send your session cookies for banking.com along with the request. It's just that evil.com can't read the response content.

I thought the browser at evil.com would first send a pre-fetch request without the cookies, but not send the full request when it doesn't get the correct value from Access-Control-Allow-Origin in the response from banking.com. I'll admit I may be one of the developers that doesn't understand CORS...

I think you could implement that with CORS + CSRF tokens (blocking all types of Cross-Origin requests) but the default behaviour is to allow Cross-Origin writes (e.g. with form submissions).

See https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

This is why we have CSRF tokens. So that you can effectively block Cross-Origin writes.

Post reply on HN