ClickOnce Deployment and Security
Applications that are deployed using ClickOnce technology are restricted to a set of permissions and actions that are defined by the security zone. Security zones are defined in Internet Explorer, and are based on the location of the application. The following table lists the default permissions based on the deployment location:
Deployment Location |
Security Zone |
|---|---|
Run from Web |
Internet Zone |
Install from Web |
Internet Zone |
Install from network file share |
Intranet Zone |
Install from CD-ROM |
Full Trust |
The default permissions are based on the location from which the original version of the application was deployed; updates to the application will inherit those permissions. If the application is configured to check for updates from a Web or network location and a newer version is available, the original installation can receive permissions for the Internet or Intranet zone instead of full-trust permissions. To prevent users from being prompted, a System Administrator can specify a ClickOnce deployment policy that defines a specific application publisher as a trusted source. For computers on which this policy is deployed, permissions will be granted automatically and the user will not be prompted.
Security and Permissions
As a developer, it is your responsibility to make sure that your application will run with the appropriate permissions.
Note
Visual Studio enables you to debug your application in the target security zone and provides help in developing secure applications.
There are cases where a ClickOnce application may require elevated permissions. For example, an application that has to interact with an Excel spreadsheet would require permissions beyond those defined for the Internet or Intranet zones. If an application requires elevated permissions, the user will be prompted during installation to grant permission. If the user accepts, the application will be installed; if not, the installation will be stopped.
Note
To prevent users from being prompted, a System Administrator can specify a ClickOnce deployment policy that defines a specific application publisher as a trusted source. On computers where this policy is deployed, permissions will automatically be granted and the user will not be prompted.
Permissions for an application are determined by the settings in the <trustInfo> Element (ClickOnce Application) element of the application manifest. Visual Studio automatically generates this information based on the settings on the project's Security property page. A ClickOnce application is granted only the specific permissions that it requests. For example, where file access requires full-trust permissions, if the application requests file-access permission, it will only be granted file-access permission, not full-trust permissions. When developing your ClickOnce application, you should make sure that you request only the specific permissions that the application needs.
In addition, the deployment manifest should be signed using Authenticode signing. Publisher information based on the Authenticode signature will be displayed to the user in the permissions dialog box during installation, to show the user that the application originated from a trusted source. The Windows Software Development Kit (SDK) includes a file-signing tool, Sign Tool (SignTool.exe), that enables you to sign the manifest. (Note that the signing tool signcode.exe has been deprecated.)
Note
Signing functionality, available in Visual Studio 2003 and earlier versions, has been removed from Setup and Deployment projects (Setup projects, Web Setup projects, Cab projects, and Merge Modules). If you have imported a Visual Studio 2003 project with signing enabled into Visual Studio 2005, or if you want to enable signing for your deployment project, you will have to sign the files in the build output with Sign Tool (SignTool.exe) in a post-build step. For information about how to do this, see The file '<file>' was not signed.
ASP.NET Form-Based Authentication
If you want to control which deployments each user can access, you should not enable anonymous access to ClickOnce applications deployed on a Web server. Rather, you would enable users access to the deployments you have installed based on a user's identity (using Windows NT authentication).
If you deploy to an environment without Windows NT authentication, a solution could be to try using ASP.NET form-based authentication to authenticate the user. However, ClickOnce does not support forms-based authentication because it uses persistent cookies; these present a security risk because they reside in the Internet Explorer cache and can be hacked. Therefore, if you are deploying ClickOnce applications, any authentication scenario besides Windows NT authentication is unsupported.
Passing Arguments
An additional security consideration occurs if you have to pass arguments into a ClickOnce application. ClickOnce enables developers to supply a query string to applications deployed over the Web. The query string takes the form of a series of name-value pairs at the end of the URL used to start the application:
http://servername.adatum.com/WindowsApp1.application?username=joeuser
By default, query-string arguments are disabled. To enable them, the attribute trustUrlParameters must be set in the application's deployment manifest. This value can be set from Visual Studio and from MageUI.exe. For detailed steps on how to enable passing query strings, see How to: Retrieve Query String Information in a ClickOnce Application.
You should never pass arguments retrieved through a query string to a database or to the command line without checking the arguments to make sure that they are safe. Unsafe arguments are ones that include database or command line escape characters that could allow a malicious user to manipulate your application into executing arbitrary commands.
Note
Query-string arguments are the only way to pass arguments to a ClickOnce application at startup. You cannot pass arguments to a ClickOnce application from the command line.
Deploying Obfuscated Assemblies
You might want to obfuscate your application by using Dotfuscator to prevent others from reverse engineering the code. However, assembly obfuscation is not integrated into the Visual Studio IDE or the ClickOnce deployment process. Therefore, you will have to perform the obfuscation outside of the deployment process, perhaps using a post-build step. After you build the project, you would perform the following steps manually, outside of Visual Studio:
Perform the obfuscation by using Dotfuscator. For more information, see Walkthrough: Manually Deploying a ClickOnce Application.
Use Mage.exe or MageUI.exe to generate the ClickOnce manifests and sign them. For more information, see Manifest Generation and Editing Tool (Mage.exe) and Manifest Generation and Editing Tool, Graphical Client (MageUI.exe).
Manually publish (copy) the files to your deployment source location (Web server, UNC share, or CD-ROM).
See Also
Concepts
Choosing a Deployment Strategy
Choosing a ClickOnce Deployment Strategy
Reference
File Signing Tool (Signcode.exe)