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

301–310 of 366 posts

Re: Developers don't understand CORS

#301

Post by sroussey »

oefrha wrote: post #283
zaroth wrote: post #277

Earlier quoted context omitted.

(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 prognosticatin…

application/x-www-form-urlencoded and multipart/form-data POSTs predate CORS. They have to be whitelisted, or large swaths of the existing web would be broken.

These things keep coming up... but how large a swath is it really?

Then again, only with TLS 1.3 do we get rid of RC4!! Except when downgrading to 1.2, 1.1, 1.0, ssl3 (is that even around?)

Re: Developers don't understand CORS

#302

Post by cakoose »

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.

It's not just the level of detail. For example, what if your advice included one fewer detail:

> The webserver listening in on "localhost:19421" should implement a REST API. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.

Do you see how that is wrong?

Re: Developers don't understand CORS

#303

Post by [deleted] »

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…

[deleted]

Re: Developers don't understand CORS

#304

Post by dagenix »

chrisfosterelli wrote: post #216
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…

The advice isn't wrong, but you did misunderstand it. The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request. You're assuming the API will remain identical, just with new headers. I didn't advise this, what they have now is not a semantically RESTful API. What they hav…

> The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request.

Then you should edit your article to say that, or at least put a caveat saying it's more complicated than you imply in your article and to go look up the details elsewhere.

If I wanted to design an API that was prone to security issues - I would design something like CORS. While I understand why some requests require pre-flights and others don't, looking at it without considering web history: it is absolutely insane that changing what appears to be a non-security related parameter (Content-Type), drastically changes how the request is executed. Making it worse, is that its super easy to ignore the Content-Type header on the server side and just assume a that the body will be whats expected. Making it even worse, is that if a request is not pre-flighted, it will be sent to the server to be executed and only the reading of the response will be blocked by a non-matching Access-Control-Allow-Origin header - which is not intuitive at all.

Re: Developers don't understand CORS

#305

Post by chrisfosterelli »

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.

> Someone could follow the advice in the article and still be vulnerable.

This applies to any advice that is not an actual reference implementation in code. There's only a state-changing GET handler because they chose to work around CORS and you can't POST for images. Implemented properly this CORS approach does protect against CSRF without the need for an explicit token. I've written more about this before, with concrete examples in Node for example: https://fosterelli.co/dangerous-use-of-express-body-parser

Re: Developers don't understand CORS

#307

Post by syntheticcdo »

DrOctagon wrote: post #251

If an HTTP API is GET request only and there is no authentication for the API, think public weather info API, is there any risks with having "Access-Control-Allow-Origin: *" set? I've tried to get my head around CORS a few times without much luck.

ACAO:* is appropriate for a publicly accessible, unauthenticated request.

Re: Developers don't understand CORS

#310

Post by mrwww »

Many beginner tutorials on web development breeze by "how to disable cors" as the most natural obvious thing to do, usually when wanting to call your own API on a subdomain. I think because it sometimes "gets in the way" and how to properly work with it requires slightly more planning than just disabling, developers fall into bad habits.
Post reply on HN