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

241–250 of 366 posts

Re: Developers don't understand CORS

#241

Post by Animats »

One of the side effects of CORS is that you can't display most off-site images through WebGL. Displaying an off-site image through is allowed. Otherwise ads would break. But you can't bring the same image into the WebGL system.

I hit this trying to display map tiles. The map tiles are on a server that doesn't send any CORS headers. A simple 2D display of the map works fine. But using a 3D library that allows rapid movement, perspective views, and flyover hits a CORS block. I can force through that with a browser add-on, but that's just for testing.

Incidentally, CORS-plugin for Firefox has a major security hole. You give it a URL to allow, but, randomly, it switches invisibly to "all URLs" and opens a security hole.

Re: Developers don't understand CORS

#242

Post by superasn »

tgsovlerkhgsel wrote: post #171
superasn wrote: post #146

Earlier quoted context omitted.

It certainly won't allow me to make xhr POST requests without sending an OPTIONS request first. Are you sure about that?

Don't trust, verify: https://news.ycombinator.com/item?id=20406633

Amazing. You learn something new everyday. Though it does make sense why blocking it won't serve any purpose as form submissions are going thru anyway.

Also glad I didn't mention jsonp. God knows what the devs at ournewbankingapp would do with that one ;)

Re: Developers don't understand CORS

#243

Post by z3t4 »

heavenlyblue wrote: post #196
z3t4 wrote: post #90

Just tried and I get CORS errors when trying to access localhost in Firefox, also on images via xmlHttp ... Edit: It works with image elements! img = document.createElement("img") img.src = "http://localhost:1337/service" Btw, CORS is a PITA when doing pure web apps, apps that doesn't requre a server. I recently made a RSS reader web app, but had to use a CORS proxy. I wonder if there is any way I can use an image el…

>> I wonder if there is any way I can use an image element to bypass CORS and read RSS xml that way !? The article in question says they used the image dimensions to encode the error codes returned by the server when making a request. I can imagine you could simply encode the payload in the dimensions of the image.

I was thinking about using img.src to replace xmlReq and Fetch. So that I can fetch sites that I do not own. eg. RSS feeds.

Re: Developers don't understand CORS

#244

Post by bzbarsky »

mehrdadn wrote: post #119
bzbarsky wrote: post #104

Earlier quoted context omitted.

CORS doesn't apply to navigations by default, so anaphor is correct: evil.com can just submit a form to banking.com and it will send the banking.com cookies. This is the whole field of CSRF (cross-site request forgery) mitigation. CORS was introduced as a way to allow requests that browsers used to not allow at all: things like cross-site XHR in the first instance. Then it was expanded so that requests that are not n…

Is my take on this also generally correct? That it wouldn't have been a problem had cookies and such been designed to take into account the origin properly (and hence why it's unintuitive and catches people off-guard)?

If cookies were scoped to the (source, target) pair, then that would remove one of the main motivations for CORS, yes: evil.com would not be able to get any information from bank.com by making your browser make the request that they could not get by doing the request server-side.

There's a second problem CORS kinda tries to solve, which is the ambient authority problem: services that run behind firewalls and assume that if someone can reach them the someone should have access. If someone runs a browser behind the firewall and opens a page on unsafe side of the firewall, that page can then issue network requests from the browser and thus end up access things on the "safe" side of the firewall. This is a large part of why CORS has the whole preflight complication and the rules around when preflights happen: the idea is that in this situation just making the request, not even receiving a response, is potentially damaging. There are the carve-outs for requests that could be generated without things like XHR that are subject to CORS (e.g. by doing a form submission or load or whatnot); if your ambient-authority-using server responds in interesting ways to those, CORS is not going to help you... The _right_ fix for this stuff, of course, is for services to stop using ambient authority and/or for browsers to block requests from public sites to private IPs. Unfortunately in practice detecting "private IPs" reliably is not trivial, because fundamentally it depends on the routing and firewall topology, which the browser doesn't really know about.

Re: Developers don't understand CORS

#245

Post by leesec »

EGreg wrote: post #239
leesec wrote: post #38

Earlier quoted context omitted.

This reads so much like the infamous dropbox comment.

How so? It's super easy to just download and put into any website. Look at the demo above. It took us about 3 months of work to get all the quirks out, but anyone can do it. A developer can grab our library but if you don't know how to code, it's just a widget you get off the Internet. And it works on YOUR WEBSITE. This isn't like Dropbox because there is no desktop app.

So you're wondering why people use something that just works over something that took you (assumedly someone technical) 3 months to get all the kinks out?

How long do you think it would take a non technical team or company to get it up and running?

Re: Developers don't understand CORS

#246

Post by vbezhenar »

edejong wrote: post #57
vbezhenar wrote: post #48

Earlier quoted context omitted.

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Sorry, I might initially have caused this mess, thinking browsers would fix it sooner than later.

Well, you need your software to work now, hard to blame you :)

I thought about this problem and there are two workarounds. First workaround is to get agreement with major CA who would allow you to issue a valid certificates for users. So it's like user installs your software, generates private key and you generate signed certificate for that key on your server. I think that plex does that, but it's probably extremely hard and fragile scheme. Second workaround would be to proxy traffic from your localhost server to your remote server. Remote server would present valid certificate for something like local.yourcompany.com and would decrypt traffic and translate it back to your localhost server. Same with response. So you're doing encryption with remote server and never leak your private key. I'm not sure if CA would be happy with that implementation, but technically I believe it's not a key compromise.

Re: Developers don't understand CORS

#247

Post by vbezhenar »

tgsovlerkhgsel wrote: post #108
rezonant wrote: post #56

Earlier quoted context omitted.

Installing trust store certificates for these purposes is asking for trouble. Sure, if the private key is unique per installation it theoretically should be fine, but in reality it can be hard to gather enough entropy to be satisfiably unpredictable, and it's very easy to get this wrong. It's worth noting that there isn't a solid way to limit your CA certificate in the trust-store to the domains you intend to use it…

Can't you just install a specific self-signed certificate for a single domain instead of a CA certificate?

Yes, you can and you should do that.

Re: Developers don't understand CORS

#248

Post by TazeTSchnitzel »

ChrisCinelli wrote: post #213
kortilla wrote: post #208

Earlier quoted context omitted.

I’m not sure you understand the threat model either. Even if the meeting ID is a GUID, you’re still leaving an avenue for people to have their visitors join arbitrary meetings.

Well, I guess I need to explicitly say that having the Zoom client asking something like: "www.visited-site.com" wants to start a meeting with you. Do you want to join? is (uncommon?) common sense that the Zoom app should follow.

They seem to have engineered this just to avoid such a prompt, because Safari brings up one when navigating to a protocol that launches an external app.

Re: Developers don't understand CORS

#249

Post by bamboozled »

Most developers I interact with don't even understand something as fundamental how a TCP connection works (not blaming) let alone something as abstract as CORs.

What are you going to do? Some things are just complicated and it's hard to find good people who actually bother to understand these systems, it's what separates the best from the rest.

Re: Developers don't understand CORS

#250

Post by cakoose »

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…

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 this particular vulnerability ("Access-Control-Allow-Origin") but not on the aspects that are:

2a. How to handle the pre-flight request, which is the thing that would actually block wrong-site requests.

2b. If you're relying on a Content-Type of "application/json" to trigger a pre-flight request, then it should be made clear that this is now a security check -- it's common for server code to ignore the Content-Type header as long as the body is valid.

Post reply on HN