Protect custom server controls in ASP. NET

Custom server controls are one way to extend the functionality of ASP. NET Web server controls. The following provides basic security guidelines for users and developers of custom server controls. For more information about creating custom server controls, see Developing Custom ASP. NET Server Controls.

IDE (such as Microsoft Visual Studio 2005) simplifies the use and development of custom controls. However, the security guidelines listed below apply regardless of which 1 IDE is used.

For general information about ASP. NET Web application security, see ASP. NET Web application security.

Guidelines for users of custom server controls

You can use custom server controls in an Web application in a number of ways, such as placing source code files directly in the App_Code folder of an Web application, using controls from the global assembly cache, or using community components installed through automated installers such as Visual Studio content installer. In all cases, precautions should be taken to prevent the import of malicious code or code that unexpectedly but negatively affects IDE and the server hosting the component.

Here are some security guidelines that users of custom server controls should consider. This list may not be comprehensive enough, but you can start to investigate from now on:

Don't use unfamiliar code or code that doesn't understand its security risks. For community components, it is recommended that you read the available publisher information and determine whether the component is signed.

Don't just consider the run-time security of the control, but also its design-time security.

If possible, use custom controls in strong-named assemblies and select trusted publishers.

Run an ASP. NET Web application that includes imported controls using the least privileged account. For more information about running the ASP. NET process with the least privileged identity, see Configuring the ASP. NET process identity. In IDE, such as Visual Studio 2005 or Visual Web Developer Express Edition, unless you need to perform administrative tasks, run the application as an ordinary user and not as an administrator.

View the operating system security and Windows access control list (ACL) on the server hosting the custom server control. For example, ensure that the ASP. NET process is run with an identity that has only the minimum permissions required to run the application, so as to minimize the impact of security vulnerabilities caused by custom server controls on other hosted applications.

Also, review the permissions for custom server controls and make sure they follow the file and folder permissions that the identity of the ASP. NET Web application must have to work properly.

Use code access security to restrict the resources that an Web application (with custom server controls) can access and the privileged operations that can be performed.

Use the. NET Framework configuration tool (Mscorcfg. msc) to manage and configure assemblies and adjust code access security policies in the global assembly cache. Because the purpose of Mscorcfg. msc is to help senior administrators perform tasks related to configuring applications, work with your system administrators to determine whether using the tool is appropriate for your situation.

Guidelines for custom server control developers

As a developer of custom controls, you should follow general best practices for security in ASP. NET application pages and controls and. NET Framework. In many cases, users of custom server controls may not know all the implementation details or security risks. However, you should plan this 1 by following established security conventions and clearly indicating all permissions required for the component to work properly. You can investigate general security issues and solutions from the ASP. NET Web site security, the. NET Framework developer's guide, the basic concepts of security, and the security topics in "Patterns ES90Practices Web site" (patterns and practices Web site).

After designing and implementing a custom Web server control, you must determine how to provide the component to the user. There are two common ways to provide it: as an assembly or as a community component. If you provide a component as an assembly, you should sign the assembly (also known as strong name signing). Signature provides a 1-only identity for an assembly that other software can use to identify and explicitly reference. At the same time, this 1 method can provide other benefits, which are described in detail in programming with assemblies.

If you provide a component as a community component with an automated installation process, you should sign the component encrypted. Signature can help verify whether data originated from a specific party by creating a digital signature that is only 1 to a specific party. One way to create a community component for Visual Studio 2005 is to use the Visual Studio content installer and create a.vsi file that can be signed.

The following are some security guidelines that should be considered when developing custom server control components. This list may not be comprehensive enough, but you can start to investigate from now on:

Along with Custom Server Control 1, it provides instructions on how to use these controls, as well as requirements for the resources and permissions required for these controls to function properly.

Digitally sign a component

If you package a custom control as an assembly, the assembly is signed with a strong name. For more information, see Creating and Using Assemblies with Strong Names. If you use an automatic installer, such as Visual Studio Content Installer, you still need to sign the component. For more information, see How to: Package Community Components to Use the Visual Studio Content Installer and How to: Package Community Components to Use Visual Studio Content Installer.

Follow best practices for exception management in code

If you want the page developer to add custom controls to the visual designer's toolbox, drag them onto the design surface and access their properties and events in the Properties Browser, and consider design-time security in addition to run-time security. For more information, see Securing Custom Control Designer Components.

Understand the highest threats to Web application pages and controls, including code injection, information disclosure, session hijacking, identity spoofing, parameter manipulation, and network listening. Therefore, the threat modeling analysis of components should be completed before deployment.