Do You Really Know CORS? • Hacker News Board

Re: Do You Really Know CORS?

#51

Post by Ajedi32 » Thu, Oct 04, 2018, 3:05 AM UTC

paulddraper wrote: post #8

3pt14159 wrote: post #6

I'm ideologically against third party on the web because it is a privacy nightmare. But I'm in the system that I'm in, and I don't take on fights that aren't possible to win, so barring my becoming a billionaire I've kinda just accepted that third party is here for at least a little while and I'm not going to refuse to use ads and analytics. Except on my personal website, that gets to stay cool. That said, CORS is th…

CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.

> And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself.

I disagree. The current model where the server has to opt-in to cross origin access by explicitly sending an Access-Control-Allow-Origin header is secure-by-default, whereas a model relying on the server to enforce access would be insecure-unless-the-server-properly-checks-the-origin-header, leading to all sorts of vulnerabilities.

Re: Do You Really Know CORS?

#52

Post by Ajedi32 » Thu, Oct 04, 2018, 3:08 AM UTC

zackmorris wrote: post #35

JepZ wrote: post #33

I never really understood why we have CORS. I mean, the problem with CSRF is that some random page can trick your browser into adding its authentication token to a request which does not originate from the authenticated page. So why the do we need the server to tell the browser that it should not send requests from other origins? In my opinion, it would have been much better to improve the browsers to not include coo…

Ya I generally think CORS is a waste of time. It would have been better to provide a hash of the file we're linking to and trust that rather than where it came from. Which is precisely what Subresource Integrity (SRI) does: https://en.wikipedia.org/wiki/Subresource_Integrity Sadly even though this is an obvious concept and trivial to implement, it took them over 20 years since the web came out to get it in most brows…

CORS is for data retrieval, not subresource inclusion. In fact, you don't need CORS at all to include a script in your page; that has never been the case.

Re: Do You Really Know CORS?

#53

Post by Ajedi32 » Thu, Oct 04, 2018, 3:12 AM UTC

uyuyhay wrote: post #47

Please explain why browsers can't request and use any url as a regular curl command does (I'm explicit talking about request without sending browser cookies)

    curl http://192.168.1.1/

Every site you visit would have unauthenticated read access to internal servers on your LAN, such as your router's home page.

Re: Do You Really Know CORS?

#54

Post by paulddraper » Thu, Oct 04, 2018, 3:14 AM UTC

mattnewton wrote: post #24

paulddraper wrote: post #15

Earlier quoted context omitted.

The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.

The people with the security problem are the users of browsers, and the browser vendors have a solution to solve that problem built into the browser. If they didn’t enforce it at the browser level, the owners of the servers would have little incentive to enforce CORS and most just wouldn’t. See https adoption.

> the owners of the servers would have little incentive to enforce CORS and most just wouldn’t

Huh? They already implement authorization. (Transport security is similar but different.)

And I've seen plenty of Allow-Origin-Access-Control: * because people get frustrated with CORS, e.g. they can't allow access for *. example.org.

Re: Do You Really Know CORS?

#55

Post by exabrial » Thu, Oct 04, 2018, 3:28 AM UTC

No... I don't despite my best efforts to be diligent about learning it. :( It's a workaround for a bunch of compromises we made where the cure is almost not worth the pain.

Re: Do You Really Know CORS?

#56

Post by stillbourne » Thu, Oct 04, 2018, 3:32 AM UTC

I am very upset that no one said "Of CORS I do!"

Re: Do You Really Know CORS?

#57

Post by bzbarsky » Thu, Oct 04, 2018, 3:51 AM UTC

inopinatus wrote: post #18

paulddraper wrote: post #8

Earlier quoted context omitted.

CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.

CORS protects users, not services, so it's entirely reasonable that the evaluation of policy occurs in the user agent.

Actually, CORS protects both.

If CORS aimed to only protect users, there would be no need for a preflight at all. The only reason preflights exist is to protect services from receiving requests they might really not expect (e.g. malformed data) and doing bad things as a result.

In particular, the idea is to protect non-publicly-routable services. Publicly-routable ones, where you can just issue an attack request with cURL or the like, have to be hardened against malformed requests to start with.

But there are tons of non-publicly-routable things (think printers and the like behind firewalls) that could be attacked via browsers that are running behind the firewall loading web pages from outside the firewall. And CORS aims to mitigate or prevent some of those attacks.

Re: Do You Really Know CORS?

#58

Post by nazri1 » Thu, Oct 04, 2018, 3:59 AM UTC

saganus wrote: post #41

Klathmon wrote: post #7

This is an awesome overview! But don't take it as all encompassing, it doesn't go into some of the more esoteric edge cases with CORS, like: * either an unreleased safari version, or the most recent version will send preflight requests even if the request meets the spec (like if the Accept-Language is set to something they don't like). * If you use the ReadableStream API with fetch in the browser, a preflight will be…

Genuine question: why do you feel you've cut your teeth more than most? I.e. what kind of dev work do you do that makes you have to deal with this more than the average developer?

The kind of work where you need to run javascript loaded from third party sites and make it do stuff to the user (advertisements, chat).

Re: Do You Really Know CORS?

#59

Post by denormalfloat » Thu, Oct 04, 2018, 4:14 AM UTC

Why not just include the Origin on all cross-origin requests? Then the server could deny/allow it without the need for preflight.

Re: Do You Really Know CORS?

#60

Post by anthuswilliams » Thu, Oct 04, 2018, 4:45 AM UTC

parhamn wrote: post #25

Im curious how many newer JS+API applications still use browser cookies as a means of authenticating API requests and how prevalent cookie usage still is for these types of applications? JWT/tokens + Local/session storage + adding fetch headers seems like the best way as long as you don't run untrusted JS.

"as long as you don't run untrusted JS" is a surprisingly tough hurdle to hit, even for very experienced developers.

What is your reason for preferring JWT + localStorage for authentication and session handling? I'm genuinely curious, as httpOnly cookies strike me as better in every meaningful way.