ClickOnce Deployment and Security
Applications that are deployed using ClickOnce technology run in a "sandbox," with a limited set of permissions based on a security zone. 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 rather than 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 ensure that your application will run with the appropriate permissions.
.gif) Note |
|---|
Visual Studio allows you to debug your application within 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 needs 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 halted.
| 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 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 be careful to 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 .NET Framework SDK includes a file-signing tool, Sign Tool (SignTool.exe), that allows 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 need to sign the files in the build output with Sign Tool (SignTool.exe) in a post-build step. For information on 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 allow anonymous access to ClickOnce applications deployed on a Web server. Rather, you would allow 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 possible solution could be to attempt 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 arises if you need to pass arguments into a ClickOnce application. ClickOnce allows 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 launch the application:
http://servername.adatum.com/WindowsApp1.application?username=joeuser
Query-string arguments are disabled by default. 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 directly to a database or to the command line without checking the arguments to ensure that they are safe. Unsafe arguments are ones that include database or command line escape characters that can 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 launch. You cannot pass arguments to a ClickOnce application from the command line. |
Deploying Obfuscated Assemblies
You might want to obfuscate your application 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 need 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 using Dotfuscator. For more information, see Walkthrough: Deploying a ClickOnce Application Manually.
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
Reference
File Signing Tool (Signcode.exe)
Concepts
Choosing a Deployment Strategy
Choosing a ClickOnce Deployment Strategy