ClickOnce Security
| ClickOnce, as you've seen, uses the manifests of the application it's about to download to analyze the application. If there are issues in one or more of four categoriespublisher, machine access, installation, and locationthose issues are flagged by ClickOnce, before displaying the Security Warning dialog. From this dialog, users can open the More Information dialog (shown earlier in Figure 19.10) to view precisely which of the security issues are flagged. Of the four categories, there isn't much you can do about ensuring that location isn't flagged. Installation is dependent on how you configured the install mode for your application: If online/offline, this category is flagged. Ensuring that the publisher and machine access categories are not flagged requires you to dip your toes into code signing and .NET's code access security (CAS). Code SigningBecause downloading code and executing it locally is akin to erecting a large neon sign saying, "Please destroy my computer!" users may feel uncomfortable about doing so. However, users also need to be able to do so. That's where Authenticode code signing technology comes into play.[20]Authenticode allows users to verify the publisher of the code they want to download, as well as hold the publisher accountable if something goes wrong, whether maliciously or accidentally.
The foundation of Authenticode is the digital certificate, which application publishers use to sign their code. In exactly the same way that Secure Sockets Layer (SSL) certificates are issued for secure web sites, digital certificates are issued to application publishers by trusted certification authorities (CAs), such as VeriSign and thawte. CAs have the power to accept or deny requests from application publishers for trust certificates. If a request is accepted, it means that a CA vouches for the application publisher, guaranteeing that the publisher is who it says it is. Additionally, the CA certifies that the application publisher is trusted to create and make claims about other keys. Either way, the resulting certificate lets downloaders know who it was that digitally signed published code. This allows users to find out exactly whom they might be downloading code from, as well as provides a mechanism by which users can deny or allow code to be downloaded. ClickOnce relies heavily on the Authenticode code signing model to ensure that absolutely no application code is downloaded, let alone installed and executed, without the express permission of the user. Digital CertificatesClickOnce applications cannot be published unless they are digitally signed by an Authenticode certificate. You should absolutely acquire a digital certificate from a CA for your publicly published applications, but if you want users to trust and use them, you can temporarily get away without a CA-provided certificate for your development environment. VS05 allows you to manually create a certificate from the Signing tab of a project's property pages by clicking the Create Test Certificate button, as shown in Figure 19.33. Figure 19.33. Viewing and Selecting Code Signing Certificates from VS05 When you create a test certificate, you are asked to password-protect it, which is obviously recommended. The resulting certificate is a .pfx file whose name conforms to the following format: ProjectName_TemporaryKey.pfx A .pfx file is a Personal Information Exchange certificate file (PKCS #12), which is a container for a digital certificate.[21] VS05 also adds this certificate to your computer's personal certificate store, as shown in Figure 19.34.[22]
Figure 19.34. Managing Certificates on a Client Machine As you can see, there are several certificate stores, although the Personal store is the library of certificates installed on your machine that are typically either for you or created by you. You gain two advantages by retaining personal certificates in the certificate store: Certificate sharing is simplified, and Windows take care of the complexities of key management. For example, applications like VS05 can ask Windows to sign code on their behalf, without their ever having to touch the private key. The advantage is that applications you may not trust with your key can still sign code for you. You can proactively select a certificate from the Personal certificate store by clicking the Select from Store button shown in Figure 19.33.[23] Additionally, you can choose a certificate that's deployed with a personal certificate file outside your project. This action imports the .pfx file into your project and loads the certificate into the certificate store. Finally, if you haven't created a test certificate when you publish your application for the first time, VS05 creates one for you.
By default, a test certificate is untrusted, which is something you can determine by viewing detailed certificate information for the selected certificate in VS05. To do this, you click the More Details button in VS05 (see Figure 19.10 earlier) or the View button in the certificate manager (Figure 19.34), which opens the dialog shown in Figure 19.35. Figure 19.35. Certificate for Untrusted Publisher as Created by VS05 You need to trust a certificate if you want to trust code signed by that certificate. Code signed by a certificate can become trusted only if the CA is listed in the certificate manager as a trust root certification authority; CAs like VeriSign and thawte already are listed there. Alternatively, you can manually add your test certificate to the Trust Root Certification Authorities list for the same effect. After you do, your certificate's details are updated to match, as shown in Figure 19.36. Figure 19.36. Certificate for Trusted Publisher Notice that the certificate is valid for only one year. Although VS05 arbitrarily chooses one year as the life span for test certificates, CAs like VeriSign and thawte always issue certificates with one-year life spans.[24] The reason? With mathematical certainty, digital certificates can be cracked. Additionally, private keys can be stolen or leaked, and certificate authorities have revocation lists for this purpose. Having certificates expire after one year prevents anyone with access to a few supercomputers from cracking them and, more importantly, protects someone who doesn't have an up-to-date revocation list.
However, it would be painful for users to have to download new versions of your application every year after a digital certificate is re-signed. Time-StampingTo avoid forcing users to re-download your application in the face of certificate expiration, a published application's digital signature can be time-stamped. This requires providing a hash of the code to a CA. Then, when the digital certificate expires, applications like Internet Explorer and ClickOnce can query a time-stamp server (typically operated by a CA) to confirm that the digital signature was created before the digital certificate expired. VS05 allows you to specify a time-stamp server for your certificate by using the Signing tab, as shown in Figure 19.37. Figure 19.37. Configure a Digital Certificate's Time-Stamp Server You should check with your CA to determine the most appropriate time-stamp server to use. Publishing Signed CodeThe certificate you choose for digitally signing your application is not used by VS05 to sign the application files themselves. Instead, VS05 signs the application manifests, which control whether any actual application files are downloaded.[25] In other words, these files act as a barrier between users and actual application code; if users don't trust them, no application is downloaded.[26]
TamperproofingBefore the application manifest and setup files are even processed, a red flag is raised if they were tampered with after being published, in the form of the Application dialog that's shown in Figure 19.38. Figure 19.38. Cannot Start Application Dialog Clicking the Details button provides a summary of the reason. For tampering of a deployment manifest that looks like the following: PLATFORM VERSION INFO ... ERROR SUMMARY Below is a summary of the errors, details of these errors are listed later in the log. * Activation of http://.../wahoo2/wahoo_1_0_0_16.application resulted in exception. Following failure messages were detected: + Exception reading manifest from http://.../wahoo2/wahoo_1_0_0_16.application: the manifest may not be valid or the file could not be opened. + Manifest XML signature is not valid. + The digital signature of the object did not verify. ... When an application is published, each file listed in a manifest file is hashed, and then the entire manifest file itself is hashed. The hash of the manifest file is then signed with the private key contained in the certificate. On the client side, the hash is recomputed by ClickOnce, and, if there is a mismatch, the XML signature in the downloaded manifest or setup files is considered invalid and the tampering exception is displayed. Trusting a Signed ApplicationIf the manifests are valid, users will see the dialog shown in Figure 19.39. Figure 19.39. Downloading an Application from an Untrusted Publisher with ClickOnce At this point, the application is confirmed to be untampered, although the publisher is still unknown. Clicking on the More Information link shows that the publisher as unverified, as with Figure 19.10 (presented earlier). If a user ignores this warning and clicks Install, the application is automatically trusted and is added to the list of Trusted Applications known to CAS.[27]
Subsequent downloads of the same application, via manifests signed with the same digital certificate, execute in true ClickOnce fashion, without the Security Warning dialog being shown. If you reuse the same .pfx file (and certificate) in a different application, users will need to trust the publisher again, because the application is different. To cause a client machine to trust a client certificate you have issued, you install it into the Trust Root Certification Authorities certificate store. If no other security warning categories are flagged, the Security Warning dialog is skipped during the launch process. If other security warnings are flagged, the Security Warning dialog is shown as in Figure 19.40. Figure 19.40. Trusted Publisher with Other Security Warnings Flagged This time around, the Publisher option in the More Information dialog is OK'd (as shown in Figure 19.41), because we've designated it as a Trust Root Certification Authority. Figure 19.41. Configuring ClickOnce Application File Dependencies So, the publisher is now known, but the client machine should know about a real publisher rather than the developer who built the application. Code Signing with a Real CertificateA real publisher is associated with a real certificate, which, as we've discussed, you need to purchase from a CA or obtain from your IT department. You then import this certificate into VS05, which requires a slightly different process from the one you use with a VS05 temporary certificate. Follow these steps (based on my thawte-issued certificate):
When the certificate is imported into your project, you can publish as usual, although VS05 asks for permission to sign your application with the chosen certificate via the dialog shown in Figure 19.42. Figure 19.42. Allowing VS05 to Sign an Application with a CA-Issued Digital Certificate After you click OK, ClickOnce and VS05 publish the application as usual. Then, when the application is launched, the Security Warning dialog contains useful publisher information, as shown in Figure 19.43. Figure 19.43. Certified Publisher Information in the Security Warning Dialog Clicking the Publisher link opens the Certificate dialog shown in Figure 19.44. Figure 19.44. Certified Publisher's Certificate Details This allows users to discover more information about the publisher and helps them decide whether to continue downloading. The Publisher section of the More Information dialog, shown in Figure 19.45, also shows the updated publisher information. Figure 19.45. Certified Publisher Information in the More Information Dialog With all this information in hand, users should feel much more comfortable about the origin of their application. But as you can see in Figure 19.45, users might not feel comfortable about what the application wants to do on their machine, as described by the Machine Access security warning. Understanding how an application should be configured to avoid this warning depends on code access security. Code Access SecurityAll .NET assemblies execute within a security sandbox provided by the .NET Framework's code access security (CAS) technology. This sandbox controls the degree of access an assembly has to a computer's resources, which can include local disks, network connections, and the Registry. CAS provides different permissions based on evidence, which is most often a matter of where the application is launched fromthe local machine, an intranet, or the Internet. Ensuring that your applications conform to these defaults is a key consideration for ClickOnce-deployed applications, because it enables you to advertise your applications as being safe, secure, and benign. To access a computer's resources, an assembly needs an appropriate set of permissions that CAS grants based on where an application has come from. To view the current permission settings on your machine, use the Microsoft .NET Framework Configuration tool (available in your Administrative Tools menu). Drilling down into the Permission Sets for the machine's Runtime Security Policy reveals a number of entries, including FullTrust, LocalIntranet, and Internet. Figure 19.46 shows the set of default Internet permissions. Figure 19.46. Drilling into a Machine's Permission Sets Permission sets apply to every assembly that is loaded by the Common Language Runtime, whether they are user-run EXEs or DLLs loaded from other assemblies. Table 19.1 compares the LocalIntranet permission set to the Internet permission set.
Assemblies are associated with a permission set in a number of ways, including the publisher, the site, the strong name, or the security zone. Most of the default code groups associate code with a zone. For example, the My_Computer_Zone is associated with the FullTrust permission set, the Local_Intranet_Zone with the LocalIntranet permission set, and the Internet_Zone with the Internet permission set. The zone an assembly comes from is determined by that assembly's path, as configured in Internet Explorer via Tools | Options | Security (see Table 19.2).
On the one hand, you've seen how CAS provides a default set of permissions to an assembly based on where it comes from. On the other hand, an assembly might require fewer, more, or different permissions from those provided by CAS. ClickOnce conveniently gives you a mechanism for requesting a custom set of permissions. Requesting PermissionsAn assembly needs a minimum set of permissions in order to execute; this set of permissions can be treated as unrelated to the set of permissions CAS grants to assemblies based on deployment location. By default, a Windows Forms application is configured to support full trust, which is a way of saying that it needs all permissions awarded to users running the application as determined by their Windows user accounts. However, even though users can elevate permissions for such an application, it's your duty to ratchet down the required set of permissions by asking only for what you need to run. In this case, you need to consider configuring your assembly to support partially trusted execution. You configure an assembly's trust level from the Security tab of the project's property pages, as shown in Figure 19.47. Figure 19.47. Managing the Security Settings of a ClickOnce-Deployed Application By default, an assembly doesn't enable ClickOnce security settings until the first time you publish it, in which case VS05 automatically enables them for full trust; or you enable it manually yourself. The resulting selection is recorded in your published application's manifest: // Wahoo.exe.manifest <?xml version="1.0" encoding="utf-8"?> <asmv1:assembly ... > ... <trustInfo> <security> <applicationRequestMinimum> <PermissionSet version="1" Unrestricted="true" SameSite="none" /> <defaultAssemblyRequest permissionSetReference="Custom" /> </applicationRequestMinimum> </security> </trustInfo> ... </asmv1:assembly> The applicationRequestMinimum tag contains all the information that ClickOnce needs on the client machine to determine which permissions are required by the application. For full trust applications, this means that the Unrestricted attribute of the PermissionSet tag is set to true. When you elect to go with partial trust, VS05 provides the means to specify the subset of permissions that you need. It supports two preconfigured permission setsLocalIntranet and Internetor it lets you create your own, as shown in Figure 19.48. Figure 19.48. Configuring ClickOnce-Required Permissions LocalIntranet and Internet correspond to the permissions provided by the LocalIntranet_Zone and Internet_Zone code groups you saw earlier. Wahoo, for example, will be deployed over the Internet, and hence the Internet zone selection. This has the effect of automatically including a request for the permissions from the Internet zone: // Wahoo.exe.manifest <?xml version="1.0" encoding="utf-8" ?> <asmv1:assembly ...> ... <trustInfo> <security> <applicationRequestMinimum> <PermissionSet SameSite="site"> <IPermission docEmphStrong">Access="Open" ... /> <IPermission Allowed="ApplicationIsolationByUser" UserQuota="512000" ... /> <IPermission Flags="Execution" ... /> <IPermission Window="SafeTopLevelWindows" Clipboard="OwnClipboard" ... /> <IPermission Level="SafePrinting" ... /> </PermissionSet> <defaultAssemblyRequest permissionSetReference="Custom" /> </applicationRequestMinimum> </security> </trustInfo> ... </asmv1:assembly> As you can see, Wahoo is now configured to request the specified permissions, and only those permissions, for the security sandbox it runs in. But this also means that you must ensure that your application code doesn't require permissions beyond those specified to avoid run-time issues. Permission ElevationWhen the set of permissions required by your application exceeds those permitted by CAS for the zone, the Machine Access security warning category is flagged (see Figure 19.49), whether or not the client's machine has been configured to trust the publisher. Figure 19.49. Trusted Publisher but Potentially Harmful Machine Access At this point, the user can either cancel application launch or elect to grant the application the additional permissions it needs, a process known as permission elevation. When permission is granted, the permission set and application signature are added to the list of trusted applications managed by CAS. The application is then downloaded, installed, and executed within a CAS security sandbox that's configured to the permissions stored by CAS for the application. Partial trust applications don't appear under their own name in the Task Manager; the CLR uses applaunch.exe to launch partial trust applications, and it's applaunch.exe that you see in Task Manager. After a publisher is trusted, permissions are granted as required and the application is executed. Users can subsequently execute and upgrade the same application as many times as they like. If users download a different application from the same publisher, however, they must go through the permission elevation process again if Machine Access is flagged. If the permissions required by an application are less than or equal to those allowed for a particular security zone, the Security Warning dialog gives the green light, provided that the publisher is trusted and the application is launched from a trusted location. If subsequent versions of an application are deployed with increased permission requirements, users are prompted to elevate permissions again. Users are not prompted if subsequent versions either maintain or reduce the required permissions.[28]
|
EAN: 2147483647
Pages: 216