Do You Really Know CORS? • Hacker News Board

Re: Do You Really Know CORS?

#121

Post by ec109685 » Sun, Oct 07, 2018, 6:24 AM UTC

paulddraper wrote: post #110

Ajedi32 wrote: post #51

Earlier quoted context omitted.

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

It's already insecure-unless-the-server-checks-the-cookie-header.

Something servers already do.

Re: Do You Really Know CORS?

#122

Post by Thu27Sep » Mon, Oct 08, 2018, 8:35 AM UTC

sbergot wrote: post #104

Thu27Sep wrote: post #87

One idea that the article doesn't convey well, in my opinion, is that the Same-Origin Policy only prevents the browser from reading the response from an HTTP server to third-party host, but it doesn't prevent the request from being issued in a first place. The CORS headers are merely a way for the server to indicate to the browser whether it is allowed to read the response of not, but it doesn't protect the server fr…

This is not entirely true. The preflight's role is exactly to prevent a post request to be sent to the server. There is no preflight only in particular cases.

This is entirely false. POST requests with headers set automatically by the user agent aren't preflight-ed. There is a preflight only in particular cases.

Re: Do You Really Know CORS?

#123

Post by graphememes » Thu, Oct 11, 2018, 6:54 PM UTC

lwansbrough wrote: post #118

acoard wrote: post #117

Earlier quoted context omitted.

>and I can validate the request based on the origin Are you talking about the HTTP referer? That's easily spoofable and can't be relied on server-side. The same-origin policy and all the CORS security is implemented in the browser itself, not in HTTP. If you need to be certain that a request originated from your own page and not another domain you need to use a CSRF token.

I'm talking about the Origin header, which is present on XHR requests and cannot be assigned by code. A CSRF token is not necessary if you require Origin because the origin is not sent with standard HTML forms.

It can be inside of insecure browsers, you're not any more secure than you were before after CORS.

Re: Do You Really Know CORS?

#124

Post by notyourday » Thu, Oct 11, 2018, 7:27 PM UTC

paulddraper wrote: post #102

notyourday wrote: post #28

Earlier quoted context omitted.

> 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. That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS p…

I don't misunderstand. My beef with CORS is that I have to encoded the validation logic into its HTTP headers. But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?

You are still thinking about a server checking if a browser is trusted to run some code on a server, when the CORS is about a browser deciding if it should trust some of the server response.

Re: Do You Really Know CORS?

#125

Post by lwansbrough » Sun, Oct 14, 2018, 3:17 AM UTC

graphememes wrote: post #123

lwansbrough wrote: post #118

Earlier quoted context omitted.

I'm talking about the Origin header, which is present on XHR requests and cannot be assigned by code. A CSRF token is not necessary if you require Origin because the origin is not sent with standard HTML forms.

It can be inside of insecure browsers, you're not any more secure than you were before after CORS.

Users with insecure browsers are subjecting themselves to security vulnerabilities, not me. In this case, the service just wouldn’t work for them. Not overly worried about those users because they represent a diminishingly small portion of our user base.

Re: Do You Really Know CORS?

#126

Post by biot » Wed, Oct 17, 2018, 5:49 AM UTC

ec109685 wrote: post #120

biot wrote: post #114

Earlier quoted context omitted.

It’s secure in a “trust the client” manner. Any server code not still doing its own authentication is in for a rude awakening.

If you don’t trust the client, there is nothing you can do. An insecure browser could spoof the origin header too.

I think you’re missing my point. While you can assume well behaved clients will reduce unwanted traffic, a malicious client will spoof everything it can. Thus, there is definitely something you can do: you should never trust the client and the server should authenticate every request (as if CORS didn’t exist) instead of assuming all requests from clients are valid.

Re: Do You Really Know CORS?

#127

Post by graphememes » Thu, Oct 18, 2018, 11:28 PM UTC

lwansbrough wrote: post #125

graphememes wrote: post #123

Earlier quoted context omitted.

It can be inside of insecure browsers, you're not any more secure than you were before after CORS.

Users with insecure browsers are subjecting themselves to security vulnerabilities, not me. In this case, the service just wouldn’t work for them. Not overly worried about those users because they represent a diminishingly small portion of our user base.

The problem is that you can be unaware. It's also not tracked as a metric. Nobody knows how large or small it is.

Also, it's easily bypassed.