Zoom, CORS, and the Web
It’s sorta sad by funny that that big Zoom vulnerability thing was ultimately related to web technology and not really the app itself.
There is this idea of custom protocols or “URL schemes.” So, like gittower://
or dropbox://
or whatever. A native app can register them, then URLs that hit them get passed to the native app. iOS has “universal links” which are coming to the web apparently. (Atishay Jain has an excellent write-up on them.) But links like that don’t leave much choice — they will open in the app. If your app has both web and native components, you might want to offer the user a choice. So, you use a regular URL instead.
In order for that web page to open up a native app, apparently, the tactic used by many is to have it communicate with a server running on localhost on your own computer which uses a URL scheme to open the native app. Clever, but I’ve heard sentiment from folks like:
- I had no idea this software was running a localhost server on my machine
- It feels weird that websites out on the wild internet can communicate with my localhost server
That’s the way it is though. But there are some protections in place. Namely: CORS (Cross-Origin Resource Sharing). Ugh. I feel like I deal with some kind of CORS problem every week of my life. But it’s important. It prevents XHR requests from websites that aren’t specifically allowed. Imagine if you visit my website, and I have your browser shoot requests over to Facebook, hoping you are logged in so I can do things on your behalf. Bad. CORS doesn’t prevent that, the same-origin policy of browsers prevents that. CORS is the mechanism to control that.
If my website tries to communicate with your website, and your website’s response doesn’t have an Access-Control-Allow-Origin
header with my domain or *
, it will fail. But not everything is subject to CORS restrictions. Images, for example, are not. We can link up images from any domain and they will return data.
Chris Foster thinks CORS and a lack of understanding of CORS was at the heart of the Zoom bug.
Zoom may have needed to get this feature out and did not understand CORS. They couldn’t make the AJAX requests without the browser disallowing the attempt. Instead, they built this image hack to work around CORS. By doing this, they opened Zoom up to a big vulnerability because n/ot only can the Zoom website trigger operations in the native client and access the response, but every other website on the internet can too.
In the wake of all this, Nicolas Bailly wrote “What you should know about CORS”:
This is often a source of confusion for newcomers because it’s not immediately apparent what CORS is supposed to achieve. Firstly CORS is not a security measure in itself, it’s actually the opposite: CORS is a way to circumvent the “Same Origin Policy” which is the security measure preventing you from making [AJAX] requests to a different domain.
The post Zoom, CORS, and the Web appeared first on CSS-Tricks.