ClickOnce security concerns

ClickOnce security concerns

Joe is among many who are skeptical about ClickOnce because of security concerns. That is understandable, because at a conceptual level software that can download off the internet and execute on your machine with little to no prompting is scary as hell.

But to come to grips with the way ClickOnce works, you first have to understand and have some trust in .NET Code Access Security. CAS is a pretty complex topic on its own, but what you really have to get your arms around with CAS and ClickOnce is that through the CAS mechanisms, programs deployed through ClickOnce will be restricted in what they can do on your machine.

ClickOnce apps will run in a security sandbox that is determined through a combination of the .NET security policy installed on your machine and where the ClickOnce application is being deployed from. Even though the app gets cached on your local machine, it will still run with the permissions granted based on where it came from, even when executed offline. With the default security policy in .NET, those permissions are extremely restrictive and therefore safe. Apps executed from the internet cannot touch your disk other than to upload files to the server, you cannot request resources from domains other than the one where the app came from, you cannot access other applcations that are running on the machine… essentially the app is running in an island where it can’t touch any resources on your machine. About the only viable attack in this scenario would be a luring attack, where the app convinces you to enter sensitive information which it can then transmit back to the site where the app came from. But then a web page could do the same thing.

The manifests that drive ClickOnce are signed with digital signatures (or at least will be by release), so you can ensure that neither the deployment information nor the files deployed have been tampered with since they were deployed.

When you first run an app that has been deployed through ClickOnce for online only use, you do get minimal prompting – just some progress information while the files are downloaded before the app launches. When you first run an app that has been deployed through ClickOnce that supports running offline, you do get prompted that something is being “installed“ on your machine. Really the only additional thing that is being installed is a Start menu shortcut and an addition to the Add/Remove Programs hive. But there is in fact prompting in this case because it goes beyond the scenario of caching temp files from the internet.

There are a lot of extra layers that you can go to with ClickOnce and security that I may blog on at some point. You can deploy security policy from a trusted source, if that souce has been identified as a trusted source on the machine at some point before the deployment attempt.

Bottom line with ClickOnce is you have to get comfortable with two things. First and foremost is that you have to understand Code Access Security and trust in the protections it provides. It is part of the .NET runtime, and if you can’t trust that, then you might as well not build .NET apps that you plan to connect to the internet. The other is that you need to keep in mind the primary environment ClickOnce is targeted at: large scale enterprise line of business application deployment over partially trusted networks such as a corporate LAN.

I think ClickOnce has enormous potential to enable people to build rich distributed applications using Windows Forms instead of web pages. But I also think that the biggest barrier to adoption is getting people educated on the security mechanisms that ClickOnce provides and getting them comfortable with the fact that by default, a ClickOnce app cannot compromise your machine.