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

241–250 of 285 posts

Re: Developers don't understand CORS (2019)

#241

Post by JimDabell »

embedding-shape wrote: post #181
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.

Back in the day when I started web development, websites making their own requests after they loaded wasn't a thing. Eventually, XMLHttpRequest appeared, which let JS do HTTP requests at (page) runtime, and the whole "AJAX movement" kicked off. Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this…

> Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin.

I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty much straight away – Netscape 2.0.2 I believe. Almost 20 years passed and then CORS was created. So while it’s technically true, the timeframe in which JavaScript could make any cross-origin requests was basically the blink of an eye, and for all intents and purposes, the SOP has been around since the beginning and definitely many, many years before Ajax came around.

Re: Developers don't understand CORS (2019)

#242

Post by JimDabell »

kittywantsbacon wrote: post #61

[flagged]

I think perhaps it’s generational.

If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy.

If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser understands that it isn’t allowed; the browser tries to do a CORS preflight request; the preflight request fails; and the browser reports a CORS error in the console.

So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it.

It doesn’t help matters that a whole bunch of people with the same misunderstanding will confidently repeat that misunderstanding in tutorials and online discussions.

Re: Developers don't understand CORS (2019)

#243

Post by brazukadev »

JimDabell wrote: post #242
kittywantsbacon wrote: post #61

[flagged]

I think perhaps it’s generational. If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy. If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser unde…

> So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it.

Great explanation. The name is quite obvious actually, Cross-Origin Resource Sharing. People should understand if they read it.

Re: Developers don't understand CORS (2019)

#244

Post by [deleted] »

Sophira wrote: post #178
TeMPOraL wrote: post #165

Earlier quoted context omitted.

> I mean, it still relies on a vulnerable configuration (not checking the content type) Unless I'm misunderstanding the claim, that's not "vulnerable configuration", but extreme lunacy - basically treating parsing outcome as access control. "Did the payload parse correctly as JSON? No -> go away; Yes -> oh that must mean you're supposed to be here". I'm at a loss of words that this is even a problem in practice. > Fo…

Regarding the first part, it's easier than you might think to have a false sense of security. I've seen a web application that did, in fact, check the Content-Type header to make sure that "application/json" was there - but it didn't check that the header value started with that. That meant that setting the header to "multipart/form-data; boundary=application/json" was enough to bypass a CORS preflight!

[deleted]

Re: Developers don't understand CORS (2019)

#245

Post by brazukadev »

lofaszvanitt wrote: post #126

Because they don't like reading docs. At the same time it is an overcomplicated fucking mess, just like CSP headers just like css syntax/wording. Somehow everything that is security related is overly complex.... it's a miracle!

the browser security model is quite efficient and heavily tested tho.

Re: Developers don't understand CORS (2019)

#246

Post by cyphar »

mr_toad wrote: post #205
cyphar wrote: post #132

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. Isn't that what CSRF protections are for, not CORS? There are other (very old) ways to trick a user into doing a POST that wouldn't be blocked by CORS -- and as you say, GET and some POST requests can always be sent but you don'…

> Isn't that what CSRF protections are for, not CORS? Without the same origin policy CSRF protections would be trivial to circumvent, since you’d be able to read the CSRF token from any page.

Sure, but that falls under the "no unauthorised GET data" thing I talked about...?

Re: Developers don't understand CORS (2019)

#248

Post by xigoi »

eurleif wrote: post #69
ralusek wrote: post #63

I understand CORS and I don't. TL;DR: It's a restriction your browser gives itself . If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call. I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simp…

The part you may be missing is that cookies exist. User visits A.com, types in their username and password, and a cookie is set in their browser. The browser will send that cookie back to A.com with all subsequent requests, and A.com's server will use it to enable access to the user's account. Now the user visits B.com, which makes a request to A.com/private_user_data. The user's cookie is sent with this request, so…

Why not just not send cookies instead of blocking the request completely?

Re: Developers don't understand CORS (2019)

#250

Post by ctidd »

webstrand wrote: post #47
ctidd wrote: post #34

Earlier quoted context omitted.

All CORS does is allow for selective loosening of anti-CSRF controls. CORS is a mechanism for a service to tell a client “I’m CSRF-resistant” so that that the client doesn’t need to protect its user as tightly when interacting with that service.

Isn't CSRF about forging mutating requests? CORS doesn't block the underlying GET/POST request, the request still goes through and the server still needs to properly implement CSRF prevention. CORS just prevents javascript from reading the response. CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it bloc…

CSRF can compromise the non-mutating path as well to exfiltrate data, but the mutating path and non-mutating are different, hence the OPTIONS preflight required prior to sending mutating requests.

The browser enforces the same-origin policy by preventing read on non-mutating (i.e. “simple”) request responses and preventing sending of mutating requests (i.e. non-“simple”). CORS provides a protocol for a service to loosen these controls.

Post reply on HN