Developers don't understand CORS • Hacker News Board

Re: Developers don't understand CORS

#91

Post by anaphor » Wed, Jul 10, 2019, 7:55 PM UTC

pixelperfect wrote: post #86

anaphor wrote: post #60

Earlier quoted context omitted.

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 see what you mean, evil.com could still make a request that includes cookies, which is why we need CSRF tokens. But from my understanding, it wouldn't be able to do that in a XMLHttpRequest hidden on the page. It would have to be a request from something like submitting a form which would navigate the user off the page. Is that correct? Of course it doesn't make much difference from a security perspective.

You can work around that by submitting it within an invisible iframe element, e.g. https://stackoverflow.com/a/17953761/903589

But yeah, you can't just make arbitrary requests like this with XHR

Re: Developers don't understand CORS

#92

Post by chpmrc » Wed, Jul 10, 2019, 7:55 PM UTC

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

Re: Developers don't understand CORS

#93

Post by Spivak » Wed, Jul 10, 2019, 7:55 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.

Plex solved this problem is pretty much the way you describe.

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

Re: Developers don't understand CORS

#94

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

jedberg wrote: post #69

icebraining wrote: post #65

Earlier quoted context omitted.

But were the headers reaching the browser or not? CORS is something strictly for the browsers to parse, so if it's reaching the browser, either the policy is wrong (and you can usually see that in the browser console, when it blocks the cross-domain request) or it's not a CORS problem.

It wasn’t reaching the browser.

Seems like you have to whitelist the headers: https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

Re: Developers don't understand CORS

#95

Post by untog » Wed, Jul 10, 2019, 7:56 PM UTC

jrudolph wrote: post #80

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

> Remove cookies and basic auth headers, what's the point of CORS?

The ability to communicate with a domain other than the one your app is running on. For instance, if my site on www.example.com wants to send a POST to www.example2.com, I need CORS. example2.com needs CORS to specify that only example.com is allowed to send a POST to it, not anyoldaddress.com. example2.com could look at the Origin header and refuse connections, but it would be vulnerable to DDOS attacks.

Now, if your SPA is entirely self-contained and self-hosted then no, you don't need CORS. But there are plenty of situations where that isn't the case.

Re: Developers don't understand CORS

#96

Post by untog » Wed, Jul 10, 2019, 7:58 PM UTC

chpmrc wrote: post #92

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

Browsers are ubiquitous, and they run third party code. That would be a deadly combination for anyone hoping to launch a DDOS attack if CORS protections didn't exist.

Re: Developers don't understand CORS

#97

Post by [deleted] » Wed, Jul 10, 2019, 7:58 PM UTC

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

[deleted]

Re: Developers don't understand CORS

#98

Post by jimmychangas » Wed, Jul 10, 2019, 8:00 PM UTC

chpmrc wrote: post #92

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

The default cross-origin blocking behavior is useful for many things, such prevention of data exfiltration via XSS vulnerabilties. CORS is a way to relax this behavior.

Re: Developers don't understand CORS

#99

Post by falcolas » Wed, Jul 10, 2019, 8:00 PM UTC

icebraining wrote: post #53

leowoo91 wrote: post #26

Earlier quoted context omitted.

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.

But only one domain at a time. The lack of a way to specify multiple domains in a header makes it absurdly painful to actually implement when you want to make your content available to a specific set of domains.

I’m personally at the point where I’d rather handle unnecessary request authentication than trying to do anything with CORS.

Re: Developers don't understand CORS

#100

Post by politician » Wed, Jul 10, 2019, 8:01 PM UTC

jonstaab wrote: post #66

theturtletalks wrote: post #27

Earlier quoted context omitted.

Can you point me to some documentation for dynamically allow-origin header? I’m working on open sourcing our frontend and so if users have their own frontend on their own domain, how do we allow those calls to our backend with CORS? If we turn CORS off, is this a security issue? From the frontend, we send a JWT with the header and check this for protected routes on the backend.

CORS is really pretty simple, it's getting the threat model that is tricky. Some docs on Allow-Origin here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac... and a more complete walkthrough here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS Dynamic allow-origin sounds magical, but is really straightforward. You just look at the `Origin` header of a request (e.g., in express `req.headers['Origi…

It's not fair to call Dynamic Allow-Origin simple. This is super tricky and nonstandard usage that is only necessary to workaround the fact that browsers do not support multiple values on the Allow-Origin header even though the spec allows it.

That said, yes, when you want to allow multiple origins, reflecting the Origin request header in the Allow-Origin response header is the only solution that works. (Note however, that sometimes the Origin header is not present, an additional difficulty.)