Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS (2019)

fosterelli.co

Post reply on HN
Print view View original

191–200 of 285 posts

Re: Developers don't understand CORS (2019)

#191

Post by bazoom42 »

debazel wrote: post #130
bazoom42 wrote: post #114

Earlier quoted context omitted.

Example: I post “fungame.com” on Show HN, you visit it, and in the background the JavaScript calls Facebook on your behalf (using your Facebook authentication cookie) and adds me as friend. By default such cross-domain requests from JavaScript are disallowed, but CORS allows it if the server specifically opt-in. But the check happen in the browser, since the purpose is to protect the user of the browser. There are so…

Is there a reason this has to happen client side with extra pre-flight requests? Taking your example, why couldn't Facebook's server just check the origin header and then reject all request from unapproved origins server side instead?

It is the difference between opt-in and opt-out.

Servers certainly can (and probably should) check request origin. But it is not something they usually do, since cross-domain requests from JavaScript wasn’t possible before CORS.

If support for cross-domain request were introduced in browsers without requiring opt-in from servers, most sites would not be prepared against this new risk. It would open massive security issues across the web.

Re: Developers don't understand CORS (2019)

#192

Post by xg15 »

TeMPOraL wrote: post #167
xg15 wrote: post #164

Earlier quoted context omitted.

I wasn't aware that plaintext was one of the whitelisted types that are allowed without a preflight request. I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data > Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"? For better or worse, yes, or at least as one layer. That's on…

> I wasn't aware that plaintext was one of the whitelisted types that are allowed without a preflight request. Until now, I wasn't aware of that either. My response is about the fact you can massage the plaintext part to contain valid JSON somehow being a problem , one that apparently is a security issue in practice. We're not talking about some clever polyglot quine like those COM executables that are somehow also v…

> text/plain is a superset of everything that can be represented by plain text

Not in the context of web forms.

Just checked the spec and "text/plain" just seems to be an alias for "application/x-www-form-urlencoded" [1] - i.e. stuff that looks like

  key=value&anotherkey=anothervalue
on the wire.

Apparently though, keys and values can contain arbitrary characters and arent percent-encoded, so you can do a "quine" where the "key" is

  {"foo": "bar", "ignore": "
and the "value" is

  "}
And then the browser will happily send

  {"foo": "bar", "ignore": "="}
over the wire, which is valid json.

[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...

Re: Developers don't understand CORS (2019)

#193

Post by mr_toad »

Beltiras wrote: post #143
RobotToaster wrote: post #73

Earlier quoted context omitted.

It seems like nobody understands CORS. Including me TBH.

I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.

CORS isn’t designed to increase security, since the same-origin policy is a secure default.

It’s a mechanism to allow pages to access servers that they can’t by default - with the permission of the server operator.

Re: Developers don't understand CORS (2019)

#195

Post by [deleted] »

Sophira wrote: post #184
xg15 wrote: post #151

Earlier quoted context omitted.

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

> ...there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format... The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript: var xhr = new XMLHttpRequest(); var url = "http://localhost:12345/endpoint"; xhr.open("POST", url, true)…

[deleted]

Re: Developers don't understand CORS (2019)

#196

Post by embedding-shape »

mr_toad wrote: post #193
Beltiras wrote: post #143

Earlier quoted context omitted.

I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.

CORS isn’t designed to increase security, since the same-origin policy is a secure default. It’s a mechanism to allow pages to access servers that they can’t by default - with the permission of the server operator.

Yeah, basically Same-Origin Policy (https://en.wikipedia.org/wiki/Same-origin_policy) was the part that increased security, as it prevented websites (in browsers) from making arbitrary requests to arbitrary 3rd party websites.

Cross-Origin Resource Sharing (https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is one way to relax the Same-Origin Policy, so you essentially whitelist what actually can be shared across Origins. To be used when the default Same-Origin Policy is too strict.

Overall I think it's a really simple concept, but libraries/frameworks/docs seems to constantly over-complicate it with their explanations.

Re: Developers don't understand CORS (2019)

#197

Post by xg15 »

Sophira wrote: post #184
xg15 wrote: post #151

Earlier quoted context omitted.

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

> ...there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format... The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript: var xhr = new XMLHttpRequest(); var url = "http://localhost:12345/endpoint"; xhr.open("POST", url, true)…

Interesting. Is this still sent as a "safe" request though or does it trigger a preflight request etc?

Re: Developers don't understand CORS (2019)

#198

Post by mr_toad »

hn_throwaway_99 wrote: post #28
yaur wrote: post #18

Earlier quoted context omitted.

It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.

> in the cors threat model an attacker gets one your users to take an action on your site by visiting their site This is really oversimplifying things, incorrectly IMO, and that sentence makes it sound like you're confusing a CSRF vulnerability with CORS protections. Normally when you write a backend server you implement some sort of authentication and access control, and in that scenario the threat model that lets "…

> CORS rules only prevent the JavaScript web client from reading the response

To nitpick, it’s the same origin policy that does that.

Re: Developers don't understand CORS (2019)

#199

Post by RagingCactus »

Sophira wrote: post #184
xg15 wrote: post #151

Earlier quoted context omitted.

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

> ...there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format... The browser basically never forces you into a particular format. You don't even need to do the trick with the form stuff that the sibling was talking about. Consider the following JavaScript: var xhr = new XMLHttpRequest(); var url = "http://localhost:12345/endpoint"; xhr.open("POST", url, true)…

You can do that, but my understanding is you can't get the browser to attach cookies to your request in this way, while you can with forms. Do you agree?

Re: Developers don't understand CORS (2019)

#200

Post by spl757 »

Lerc wrote: post #54
muvlon wrote: post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

I don't think you can even say CORS does that. The degree to which CORS is poorly understood (I have read numerous (often contradictory) documentation and I don't really understand it.) means that you can't rely on it being implemented properly by an unknown party, If a protocol reaches this level of widespread confusion, I think all bets are off. Even if one end of a system performs correctly, who's to say that the…

A poorly documented, poorly implememented, and poorly understood protocol is a worthless protocol. More than that, it's a potential attack surface, and the idea is to reduce those. If you are the admin of something, and you are putting things into production in which you don't fully understand the implications, because you copy/pasted some crap from stackexchange assuming the person that posted it knew what they are talking about, then you are doing it wrong. Just look at this thread. It's chaos and reinforces the fact that even people that think they know, don't really know. When in doubt, grab the RFC and figure it out.
Post reply on HN