A problem worse than Zoom

On macOS, an app can register to handle URL schemes. Web browsers such as Safari, Chrome, and Firefox register to handle the schemes for web pages, http or https . Non-browser apps may register to handle other URL schemes; for example, an email client may register to handle the well known mailto scheme. When a URL is opened in a web browser, and the browser itself cannot handle the URL scheme, the browser looks for another app to handle the URL. If there's a handler app for the URL scheme, then the browser will open the app and pass the URL along to that app. Thus, clicking a mailto:[email protected] link will open your email client with a new email addressed to Tim Cook.

In many cases, Safari now requires user confirmation every time that Safari opens an app that handles a custom URL scheme. You may have noticed this happen if you use my own free app StopTheNews , a tool for opening Apple News URLs in Safari instead of News app. Since constantly requiring confirmation is obviously incredibly annoying, Apple has conveniently exempted some of its own apps from the requirement. For example, macappstore and macappstores URLs will automatically open App Store app without your confirmation. Ironically, the one case in which you would most want to require confirmation! I believe that Apple also exempts Radar, its internal bug reporting app used by Apple engineers. If you've ever seen an engineer mention a URL with a scheme such as radar or rdar , those URLs open in Radar app. So Apple inflicts confirmation dialogs on users outside of Apple, but it relieves its own engineers of having to confirm everything when they're working on Apple software. How thoughtful.

In order to avoid these annoying Safari confirmation dialogs that pop up not just once but every time, Zoom implemented a little trick. Instead of using a custom URL scheme for their app, they decided to install a localhost web server on the Mac. When a user loaded their web page in Safari, their web page would send a request to the localhost server for a Zoom meeting. The localhost server would receive the request and open the Zoom app to start the meeting. Since there was no custom URL scheme involved, the Safari confirmation requirement was not triggered. Unfortunately, Zoom messed up their implementation in a number of ways. The worst problem was a vulnerability that allowed a maliciously crafted web page to add a Zoom user to a meeting without their consent.

Zoom is certainly deserving of criticism. But I've seen very few people stop to ask, how was Zoom's little trick even possible in the first place? Why does Safari allow a web page, zoom.us , to make requests to a localhost server? Is this possibility not surprising to you? It was surprising to me! The problem is actually worse than this. The major browsers I've tested — Safari, Chrome, Firefox — all allow web pages to send requests not only to localhost but also to any IP address on your Local Area Network! Can you believe that? I'm both astonished and horrified.

There are probably a number of web servers on your LAN. If you have an Apple TV or another AirPlay receiver, that's a web server. Nowadays most routers and modems have a web interface. In other words, they're web servers! You can use my free app Bonjeff to see the Bonjour services published on your network. Those are all servers. Can you imagine the possibility of a maliciously crafted web page loaded in Safari being able to access your router and modem? Well it's not just a possibility, it's an actuality! I tried creating some little test pages uploaded to my web site that sent requests to my Apple TV and to my router from an iframe , and they worked! These devices are typically at well known IP addresses on your LAN. Moreover, a web page can even scan your network to find the addresses of your devices. I found a recent paper by Forcepoint that discusses in detail these kinds of attacks on your LAN from the web. So security researchers are aware of this possibility, but it seems that the browser vendors are doing nothing to plug the holes in their web browsers! To be clear, browsers do place strict limitations on cross-origin requests. Nonetheless, as we've seen with the case of Zoom, and also as discussed in the linked paper, there are currently ways for attackers to bypass the cross-origin limitations.

In my opinion, web pages should not be allowed to make requests to LAN addresses unless the user has specifically and intentionally configured the browser to allow this. In general, there's no reason why a page on the internet should be allowed to access devices on your local area network. Of course, if the user enters a LAN IP into the browser location bar, this should be allowed, but that's not a cross-origin request. I personally use a localhost server to test my web sites before I upload them to production, and I'm sure that's a very common practice. However, I don't want non-localhost web sites to be able to make requests to my localhost server. That seems absurd.

On a related subject, I don't think that web browsers should be allowed open other apps at all unless the user explicitly clicks on a link with the URL scheme handled by the app. Why are web pages allowed to automatically open App Store app? Not only is this kind of behavior annoying, it's also the cause of security vulnerabilities, which is the reason Safari added a confirmation dialog. But confirmations dialogs seem like the wrong approach. They're a workaround for a bad architecture. The app should only open if I click the link, which is itself a signal of confirmation. Otherwise, external apps should not open at all. I'd even be ok with a confirmation dialog the first time I click on a link that opens a particular app for a particular URL scheme. Even a checkbox option "Don't ask me again" would be fine. This approach seems much more reasonable, perhaps even more secure in actual practice.

To support this blog please buy my apps StopTheMadness and Underpass