Developers don't understand CORS • Hacker News Board

Re: Developers don't understand CORS

#21

Post by modethirteen » Wed, Jul 10, 2019, 6:55 PM UTC

corey_moncure wrote: post #3

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…

I for sure haven't mastered CORS. What would you use instead of that? Suppose you're doing something like client-side Blazor that calls to a WebAPI project. How can you improve security by restricting the origin of access requests when your client is open to the public?

Access to an API should be managed by a proper authentication or token validation scheme. However, protecting your users' authenticated API sessions, which are presumably initialized by the forementioned authentication scheme, is what CORS enables.

CORS, when implemented correctly, ensures that a session is not hijacked by a malicious website's JavaScript in order to call your API in the context of the session (effectively masquerading as the user who authenticated with your API). This scenario assumes that there is an authentication session cookie, tied to your API domain, that the browser would pass along with any request to your API domain (of course there are SameSite cookie and third party cookie blockers that can mitigate these situations as well, but perhaps "trusted" cross domain requests are desired in this use case)

With CORS allowing traffic from anywhere on the web, you can't reliably trust that the authenticated sessions to your API are not being used in phishing / side channel attacks: I discover your are authenticated on site on foo.example.com and I send you a link to my website, evil.com. Evil.com includes JavaScript to request data from an API on foo.example.com. Your browser executes the JavaScript and makes the request and gets a response payload, and since I'm a jerk I then post that same payload to my own endpoint on evil.com to capture the data.

Of course this all assumes that you WANT your API to be accessible cross origin. If you provide an API as a product this is common, since it allows other developers to build web apps against your API. If that is not a use case, then same origin policy (and no CORS headers from the API server) is sufficient to prevent malicious domains from doing bad stuff with your users' authenticated sessions.

Re: Developers don't understand CORS

#22

Post by Etheryte » Wed, Jul 10, 2019, 6:55 PM UTC

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?

Simplified, CORS allows servers to tell browsers which requests to allow or disallow between different domains. CORS is what blocks malicious-site.xyz from making a request to your-bank.com APIs with your credentials.

Re: Developers don't understand CORS

#23

Post by pixelperfect » Wed, Jul 10, 2019, 6:57 PM UTC

mehrdadn wrote: post #11

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?

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.

Re: Developers don't understand CORS

#24

Post by EGreg » Wed, Jul 10, 2019, 6:57 PM UTC

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://yang2020.app/meeting

You can have stuff like that yourself, for free, no Zoom required. It’s open source

SPECIFICALLY what does Zoom provide? People can install wordpress easily, and 30% of the Web has. Why not for videoconferencing?

Re: Developers don't understand CORS

#25

Post by mehrdadn » Wed, Jul 10, 2019, 6:58 PM UTC

dillonmckay wrote: post #17

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…

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 should be a way to mark that cookie as such at the time that it is originally set, not having it checked post-facto. It sounds like the only reason this is done is backward-compatibility?

Re: Developers don't understand CORS

#26

Post by leowoo91 » Wed, Jul 10, 2019, 6:58 PM UTC

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.

Re: Developers don't understand CORS

#27

Post by theturtletalks » Wed, Jul 10, 2019, 6:58 PM UTC

jonstaab wrote: post #4

corey_moncure wrote: post #3

Earlier quoted context omitted.

I for sure haven't mastered CORS. What would you use instead of that? Suppose you're doing something like client-side Blazor that calls to a WebAPI project. How can you improve security by restricting the origin of access requests when your client is open to the public?

I'm not familiar with Blazor or WebAPI, but if you're not expecting requests from client-side javascript specifically, you can just use `Access-Control-Allow-Origin: null`, since non-browser clients don't respect CORS anyway. If by "open to the public" you mean "open to requests from any client domain", CORS isn't going to help. In that case I'd probably have api clients pre-register a whitelist of domains that they'…

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.

Re: Developers don't understand CORS

#28

Post by edejong » Wed, Jul 10, 2019, 6:59 PM UTC

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 blatantly obvious and you are more confused by the myriad of headers, exceptions and lifetime. In that case, I propose to read more of the spec.

Re: Developers don't understand CORS

#29

Post by stefan_ » Wed, Jul 10, 2019, 6:59 PM UTC

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.

Re: Developers don't understand CORS

#30

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

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.

Maybe, but people want to write applications that can easily interact with each other in a secure way. Trying to do that when your browser implicitly authorizes you no matter what the origin of a request is makes that extraordinarily difficult to do safely. Adding in the backwards compatibility problem makes it even worse because any solution is going to have to work with the existing methods.