Application Protocols represent a compelling attack vector because they’re the most reliable and cross-browser compatible way to escape a browser’s sandbox, and they work in many contexts (Office apps, some PDFs handlers, some chat/messaging clients, etc).
Some protocol handlers are broadly used, while others are only used for particular workflows which may not be relevant in the user or company’s day-to-day workflows.
The Edge team can already block known-unsafe protocol schemes via a browser Component Update, but that only likely to happen if the scheme is broadly exploited across the ecosystem.
An organization or individual may wish to reduce attack surface by blocking the use of unwanted protocol handlers.
To block access to a given protocol handler from browsers, you can set the URLBlocklist policies in Chrome and Edge to prevent access to those protocols from within the browser.
For example, in 2022, the ms-appinstaller handler had a security bug and many organizations that did not need this handler for their environments wished to disable it. They can set the policies:
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\URLBlockList" /v "1" /t REG_SZ /d "ms-appinstaller:*" /f
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\URLBlockList" /v "1" /t REG_SZ /d "ms-appinstaller:*" /f
After the policy is set, attempt to navigate the browser to the protocol will show an error page:
After the 2022 incident, the App Installer team also created a specific group policy to disable the MS-AppInstaller scheme within the handler itself:
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppInstaller" /v "EnableMSAppInstallerProtocol" /t REG_DWORD /d "0" /fWhen the App Installer protocol is disabled within the handler itself, invoking the protocol simply shows an error message:
Stay safe out there!
-Eric
PS: On Windows 11 today, unfortunately, there’s not always a simple way to block an arbitrary scheme for the system as a whole, unless the protocol handler application can be uninstalled entirely.
The Windows Set a default for a link type settings pane only allows you to choose a different Microsoft Store app that offers to support the protocol scheme, preventing you from unsetting the scheme entirely or pointing it to a harmless non-handler (e.g. Calculator).
To address this, we have to tell Windows that our generic little executable (saved to C:\windows\alert.exe) knows how to handle the ms-appinstaller protocol scheme, by listing it in the RegisteredApplications key with a URLAssociations key professing support:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\com.bayden.alert]
[HKEY_CLASSES_ROOT\com.bayden.alert\shell]
[HKEY_CLASSES_ROOT\com.bayden.alert\shell\open]
[HKEY_CLASSES_ROOT\com.bayden.alert\shell\open\command]
@="\"C:\\windows\\alert.exe\" \"%1\""
[HKEY_CURRENT_USER\Software\RegisteredApplications]
"BaydenAlert"="SOFTWARE\\Bayden Systems\\Alert\\Capabilities"
[HKEY_CURRENT_USER\Software\Bayden Systems\Alert]
[HKEY_CURRENT_USER\Software\Bayden Systems\Alert\Capabilities]
[HKEY_CURRENT_USER\Software\Bayden Systems\Alert\Capabilities\URLAssociations]
"ms-appinstaller"="com.bayden.alert"
After we do this, we can change the protocol handler app from the real one to our stub:
…such that subsequent attempts to invoke the handler are harmlessly displayed:
text/plain 