Writing Secure Managed Controls

Managed controls are assemblies referenced from Web pages that are downloaded to the user's computer and executed upon demand. From a code access security perspective, there are two types of managed controls: those that are run under the default security policy and those that require higher trust.

To write managed controls that are intended to run under the default security policy, you only need to know what operations are allowed by the default security policy for the intranet or Internet zones. As long as a managed control does not require more permission to execute than it receives as a result of its zone of origin, it will run. (Keep in mind that an administrator or user might decide not to grant as much permission to code from the Internet or intranet zones.) To execute managed controls that demand higher trust, the administrator or user must adjust the security policy of any computer that will run the code.

Whenever possible, managed controls should be written so that they do not require permissions that are not granted to Internet or intranet code by default. For the Internet zone, this means that code is restricted to displaying SafeTopLevelWindows and SafeSubWindows (adorned by the security system so as to prevent them from impersonating system dialogs), communicating back only to its site of origin, and using limited, isolated storage.

Code on the intranet has slightly greater permissions. For complete details, see Default Security Policy. If your control needs to access files, use databases, collect information about the client computer, and so on, it needs some higher degree of trust.

Development

High-trust controls are intended to run under a less-restrictive security policy than their origin (intranet or the Internet) would typically warrant. Most permission demands made by secure libraries, such as.NET Framework classes, perform stack walks that check all callers to ensure that they have been granted the demanded permission and that Web pages, although not managed code, are treated as callers for the purposes of security. Stack walks are performed to help prevent less-trusted code from luring highly trusted code into performing malicious operations.

Because managed controls hosted in a browser can be manipulated by active script on a Web page, that Web page is considered a caller and checked during a security stack walk to help prevent malicious Web-page authors from exploiting more highly trusted code. The consequence of treating a Web page as a caller is that a control granted a high level of trust based on its strong name or publisher certificate and run from a Web page will be prevented from performing operations not normally allowed to code originating from the same zone as the Web page itself (intranet or Internet). For more information about deployment considerations, see the next section. On the face of it, this would seem to make writing high-trust controls impossible, but code access security provides for this scenario by enabling you to selectively override the security stack walk behavior.

High-trust controls must make judicious use of Asserts to short-circuit stack walks for permissions that their callers (the Web pages from which they were run) would not normally have. When you use Asserts, you must be careful not to expose dangerous APIs that would allow malicious Web pages to perform inappropriate operations. For this reason, the level of care and security consciousness that must go into writing a high-trust control approaches that required to write a secure class library.

The following are some tips for writing securely managed controls:

• When possible, encapsulate the operations requiring high trust so that they are not exposed by the control. In this manner, you can assert the permissions required by those operations and have confidence Web pages using your control will not be able to abuse the functionality.
• If the design of your control requires that the high-trust operations it performs be exposed, consider making a site or URL identity permission demand to ensure that it can be called only by the Web pages from which you intended it to run.

Deployment

High-trust controls should always be strong-named or signed with a publisher certificate (X.509). This allows policy administrators to grant higher trust to these controls without reducing their security with regard to other intranet or Internet code. After the assembly is signed, the user must create a new code group associated with sufficient permissions, and specify that only code signed by the user's company or organization be allowed membership to the code group. After the security policy is modified in this manner, the highly trusted control will receive sufficient permission to execute.

Because security policy must be modified to allow high-trust, downloaded controls to function, deploying this type of control is much easier on a corporate intranet for which there is typically an enterprise administrator who can deploy the described policy changes to multiple client computers. In order for high-trust controls to be used over the Internet by general users with no common corporate or organizational affiliation, there must be a trust relationship between the control publisher and the user. Ultimately, the user must be comfortable using the publisher's instructions to modify the policy and to allow the high-trust control to execute. Otherwise, the control will not be allowed to run.

See Also

Introduction to Code Access Security | Writing Secure Class Libraries | Creating and Using Strong-Named Assemblies | Security Policy Management | Default Security Policy