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

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

271–280 of 366 posts

Re: Developers don't understand CORS

#271

Post by jefftk »

gmfawcett wrote: post #214
jefftk wrote: post #82

Earlier quoted context omitted.

You can still do this. The Referer header is sent by default on requests, and you can make your server interpret it to do anything you want.

This is true unless the referring URL is secured (HTTPS), and the destination URL is not. In that case a conformant user-agent will leave Referer out. https://tools.ietf.org/html/rfc7231#section-5.5.2

True, though you should run HTTPS on your site. Which means you'll get the Referer unless the other site or the user's browser has been configured to suppress it.

Re: Developers don't understand CORS

#272

Post by Splines »

WhitneyLand wrote: post #197
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.

This Teflon you're talking about, it's a thing. Not just with CORS, not just with you. For example, I've gotten decent at regular expressions a few times but have to keep relearning it. Adding insult to injury, I might relearn something from Stackoverflow, and realize afterwards I posted the answer! Not for trivial stuff. But a string of punctuation with capture groups or whatever, forget about it [1]. Any support fo…

Probably some combination of things that break principle of least surprise along with not needing to think about that thing very frequently. A good IDE and good coding standards can smooth things over.

I'm ok with regex too, but if you asked me to do something with look-behind I'd have to experiment a little to figure out how it works again.

Re: Developers don't understand CORS

#273

Post by tootie »

cakoose wrote: post #187

The blog post author doesn't understand CORS either! Their advice on how to fix the problem is wrong: > So what would a secure implementation of this feature look like? 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 localhos…

Is all of that worthless if the calls to localhost aren't encrypted?

Re: Developers don't understand CORS

#274

Post by captncraig »

edejong wrote: post #19

The reason the developers didn't use CORS is because active mixed content isn't allowed. You simply cannot call ' http://localhost' from a https domain. For a medical SaaS application which needed to communicate via USB I created a self-signed certificate during installation and added it to the trust store to be able to call active content on localhost. Previously, we used NPAPI (which, when used correctly was more s…

Wouldn't part of this be solved by using a real domain that resolves to 127.0.0.1 instead of localhost? Then you can get a real cert and embed it in the client to make local requests work properly?

Re: Developers don't understand CORS

#275

Post by wwarner »

Best CORS reference is MDN [1].

Here's a piece of unsolicited advice: avoid CORS if you can. For user facing web apps, put your APIs behind a proxy. For a dev environment in which you want to mix local assets with production assets, use a proxy. In general, if you can't solve a cross origin problem with a proxy server, then you should really stop and reconsider what you're trying to do.

CORS is full of unpleasant subtleties, as many of the comments below illustrate. Different browsers implement CORS differently. Want to cache that preflight request? You'll use the header `Access-Control-Max-Age` for that. Except Chrome doesn't respect respect that header; the cache TTL is actually hardcoded to 10 minutes [2]. Except, according to this bug [3], Chrome will respect your cache headers starting in July.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

[2] https://stackoverflow.com/a/23549398

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=131368

Re: Developers don't understand CORS

#276

Post by Thorrez »

chrisfosterelli wrote: post #257
cakoose wrote: post #250

Earlier quoted context omitted.

No, I wasn't assuming the API will remain identical -- I saw the "should implement a REST API" part of your recommendation. Here's what's wrong with your recommendation: 1. An AJAX REST API request doesn't necessarily mean "application/json". It could also be "application/x-www-form-urlencoded", which won't necessarily trigger a pre-flight request. 2. Your advice goes into detail on an aspect that is not the crux of…

Ah I see -- so it sounds like you agree the advice is not wrong, but it's not in the level of detail you would like. It is only a 500 character example unfortunately, the details of the server API are not really in the scope of my post but I appreciate you elaborating here.

The advice is wrong. Someone could follow the advice in the article and still be vulnerable. The article should mention the actual vulnerability: CSRF, because there's a state-changing HTTP handler with no CSRF protection. CORS doesn't automatically protect against CSRF, and people shouldn't be given that impression.

Re: Developers don't understand CORS

#277

Post by zaroth »

oefrha wrote: post #238
avodonosov wrote: post #218

Earlier quoted context omitted.

You are right, and reading this the cases are not really exceptional but rather usual; so yes, it's better to not rely on CORS for protection in this case.

Not really, you can just check that Content-Type is application/json and refuse to do anything if it’s not. That effectively shuts down application/x-www-url-encoded or multipart/form-data CSRFs. In fact, parsing POST payload as JSON without checking Content-Type first is frowned upon, and some frameworks refuse to do that by default.

(Throws up hands) But this is ridiculous!

The security of the API can’t rely on strict validation of the content-type, how is that code supposed to make any sense to the 3rd generation of developers who are tasked to maintain it 5 years from now?

CORS is clearly not designed as a means of access control to ensure the POST request will never be made. Therefore, it is fairly catastrophic that an article prognosticating about how nobody bloody well understands CORS has also gotten it terribly wrong.

What this tells me is that there is probably big money in bug bounties for finding sites which use CORS for access control, and almost certainly are not checking the content-type.

Re: Developers don't understand CORS

#278

Post by Thorrez »

ChrisCinelli wrote: post #198
cakoose wrote: post #187

The blog post author doesn't understand CORS either! Their advice on how to fix the problem is wrong: > So what would a secure implementation of this feature look like? 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 localhos…

> "Access-Control-Allow-Origin" doesn't block the request from going through, it just prevents wrong-origin Javascript from accessing the response." On a GET request (like the one generated by a IMG tag) and all the other cases that do not require a pre-flight request ( https://www.w3.org/TR/cors/#preflight-request ) this is correct. Are we clear on the thread model and what Zoom is trying to do? As far as I know, Zo…

The threat model seems to have 2 requirements:

1. Only if the top level url bar says zoom.us is it allowed to cause any noticeable change to the zoom native app. This means some arbitrary website cannot cause any noticeable change to the zoom native app without redirecting you to zoom.us . This also means that a sandboxed iframe, such as an embedded web ad, has no possible way to cause a noticeable change to the zoom native app, because it is not able to do top level navigation to zoom.us .

2. When the zoom native app is triggered, the user must click yes on a confirmation button before joining the meeting.

I don't see people advocating that you need to be logged in to zoom.us .

Achieving requirement 1 without requirement 2 is still bad, because some website could redirect to zoom.us and force you into a meeting.

Achieving requirement 2 without requirement 1 is not too bad, but is annoying, because some sandboxed ad in a website could cause the zoom native app to pop up, annoying you, and could maybe almost be a DOS.

Re: Developers don't understand CORS

#279

Post by eranation »

Thorrez wrote: post #276
chrisfosterelli wrote: post #257

Earlier quoted context omitted.

Ah I see -- so it sounds like you agree the advice is not wrong, but it's not in the level of detail you would like. It is only a 500 character example unfortunately, the details of the server API are not really in the scope of my post but I appreciate you elaborating here.

The advice is wrong. Someone could follow the advice in the article and still be vulnerable. The article should mention the actual vulnerability: CSRF, because there's a state-changing HTTP handler with no CSRF protection. CORS doesn't automatically protect against CSRF, and people shouldn't be given that impression.

I've been seeing more and more developers not being aware about CSRF. Maybe the reason is that frameworks got very good built in support for CSRF protection, which caused CSRF vulnerabilities to be less common, which lead to OWASP to remove it from #8 on the list in 2013 to to not be explicitly on the top 10 at all in 2017. (marked as "Merged or retired, but not forgotten"): https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29...) but it's still a very valid vulnerability that I think every developer should understand.

Re: Developers don't understand CORS

#280

Post by Thorrez »

tootie wrote: post #273
cakoose wrote: post #187

The blog post author doesn't understand CORS either! Their advice on how to fix the problem is wrong: > So what would a secure implementation of this feature look like? 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 localhos…

Is all of that worthless if the calls to localhost aren't encrypted?

All of what worthless? The advice that cakoose gives seems quite valid to me without any encryption to localhost.

What do you mean encrypt calls to localhost? Encrypt with https? That sounds hard since you can't get a real CA to issue you such a cert. I don't see much point in encrypting with https because people off your machine can't sniff or intercept your connection to localhost. Is your goal to protect yourself from other programs or users on your same machine? That might be a valid concern on a machine with multiple users, but definitely makes the problem harder.

Or do you want some custom application-level encryption? I can't think of a good way to implement that either, but maybe it's possible.

But since I don't know what attacks you're trying to protect against, I can't tell whether there's any benefit at all to encryption.

Post reply on HN