Developers don't understand CORS • Hacker News Board

Re: Developers don't understand CORS

#71

Post by boudin » Wed, Jul 10, 2019, 7:36 PM UTC

thrusong wrote: post #46

I sort of get it and yet even when I'm sure I've configured it correctly, I'll hit road blocks in Safari, for example, when it works everywhere else as expected. It is such a frustrating experience.

Yeah, i'm dealing with CORS issue with Safari right now. On a XHR with a custom header over https, safari fails with a "protocol error" error rather than running the pre-flight request. The same query without the custom header works well. Every other browser (IE, Edge, Chrome, Firefox) handle it well and does the OPTIONS call to ensure I allow this header. If anybody has a solution for that, I'm all ears :)

Re: Developers don't understand CORS

#72

Post by pil4rin » Wed, Jul 10, 2019, 7:36 PM UTC

klodolph wrote: post #67

therein wrote: post #40

Earlier quoted context omitted.

> In that case, I propose to read more of the spec. Ingest more teflon when in doubt about its toxicity.

But Teflon is non-toxic and biocompatible. You can eat it, your body is unable to process it or break it down and it will pass through your digestive system. You can coat surgical instruments and medical implants with Teflon. (Above 300°C Teflon will generate toxic fumes, but then again, so will wood.)

Wood tastes better

Re: Developers don't understand CORS

#73

Post by azdle » Wed, Jul 10, 2019, 7:36 PM UTC

jdfellow wrote: post #50

yeldarb wrote: post #43

Earlier quoted context omitted.

Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?

No, because you'd have to distribute the private key for the local webserver to be able to sign the connection challenge.

But that's just a reason why it would be a bad idea, not a reason that they couldn't do it or that it wouldn't work.

I would think that they could distribute the cert (and the key) and have it work. [Edit] Unless browsers detect that it's a local IP address behind the domain name and still consider it a special case of origin.

Re: Developers don't understand CORS

#74

Post by alexchamberlain » Wed, Jul 10, 2019, 7:36 PM UTC

I don't really understand how CORS adds much security wise; it relies on the web browser behaving and respecting your policy...

Re: Developers don't understand CORS

#75

Post by icebraining » Wed, Jul 10, 2019, 7:37 PM UTC

anaphor wrote: post #60

pixelperfect wrote: post #54

Earlier quoted context omitted.

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.

I think pixelperfect is talking about preflights.

Re: Developers don't understand CORS

#76

Post by smallnamespace » Wed, Jul 10, 2019, 7:40 PM UTC

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…

It seems that the Chromium patches are from 2016, so presumably this would still break older Chrome users?

2016 is in the 50s, and this[1] claims that version [1] https://www.w3schools.com/browsers/browsers_chrome.asp

Re: Developers don't understand CORS

#77

Post by therein » Wed, Jul 10, 2019, 7:43 PM UTC

klodolph wrote: post #67

therein wrote: post #40

Earlier quoted context omitted.

> In that case, I propose to read more of the spec. Ingest more teflon when in doubt about its toxicity.

But Teflon is non-toxic and biocompatible. You can eat it, your body is unable to process it or break it down and it will pass through your digestive system. You can coat surgical instruments and medical implants with Teflon. (Above 300°C Teflon will generate toxic fumes, but then again, so will wood.)

> Above 300°C Teflon will generate toxic fumes, but then again, so will wood

Unless you are a parrot. I've heard it is disproportionately toxic to birds. (or is it just parrots?)

Re: Developers don't understand CORS

#78

Post by sascha_sl » Wed, Jul 10, 2019, 7:43 PM UTC

jdfellow wrote: post #50

yeldarb wrote: post #43

Earlier quoted context omitted.

Could they sign and distribute a cert for localhost.zoom.us and point the DNS at 127.0.0.1?

No, because you'd have to distribute the private key for the local webserver to be able to sign the connection challenge.

it's not the nicest solution, but I don't see the problem with a public certificate and public private key (yeah not the most elegant wording) that is literally issued to `localhost` or `127.0.0.1` (not localhost.zoom.us because that still goes through DNS once and could be hijacked)

Re: Developers don't understand CORS

#79

Post by raxxorrax » Wed, Jul 10, 2019, 7:45 PM UTC

Wouldn't this be stopped by address translation by routers for normal users? Don't know much about the app itself...

Re: Developers don't understand CORS

#80

Post by jrudolph » Wed, Jul 10, 2019, 7:47 PM UTC

CORS is a minefield. It doesn't help that the RFC is incredibly dense. I may be totally missing something, but I've repeatedly wondered though if CORS still has its place in times of SPAs that exclusively use xhr + javascript + some sort of auth token talking to a REST API?

Consider this argument: CORS basically ensures that browser and servers cooperate to protect end users from a "smart" user agent that happily throws around cookies and/or auth tokens. Remove cookies and basic auth headers, what's the point of CORS?

Happy to hear thoughts from folks more knowledgeable in web security than me. If not, let's please get together to propose an RFC for the CORS-GTFO header (a server header indicating that a browser does not have to do wasteful preflights etc.)