Asp. NET to protect custom server controls _ Practical tips

Custom server controls are a 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.

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

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 Web applications in a variety of ways, for example, you can place source code files directly in the App_Code folder of your Web application, use controls from the global assembly cache, or use an automatic installer, such as the Visual Studio Content Installer ) installed community components. In any case, precautions should be taken to prevent the import of malicious code or unexpected but negatively affected code for the IDE and the server hosting the component.

The following provides some security guidelines that users of a custom server control should consider. This list may not be comprehensive enough, but you can start a survey from here:

Do not use unfamiliar code or code that does not understand its security implications. 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 control's run-time security, but also its design-time security.

If possible, use a custom control in a strong-named assembly and select a trusted publisher.

Run an asp.net Web application that includes imported controls with a least privileged account. For more information about running the ASP.net process with an identity with the least privilege, see Configuring the ASP.net process identity. In an IDE such as Visual Studio 2005 or Visual Web Developer Express Edition, unless you need to perform administrative tasks, run the application as a normal user rather than as an administrator.

View the operating system security and the Windows access Control List (ACL) on the server that hosts the custom server control. For example, be sure to run the ASP.net process with an identity that has only the minimum permissions that are required to run the application, so that the security vulnerabilities caused by custom server controls can be minimized by the impact of other hosted applications.

In addition, view the permissions of custom server controls and ensure that they follow file and folder permissions, and that the identity of the ASP.net Web application must have that permission to work correctly.

Use code access security to limit the resources that a 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 in the global assembly cache and to adjust code access security policies. Because the purpose of Mscorcfg.msc is to help senior administrators perform tasks related to configuring an application, work with your system administrator to determine whether the tool is appropriate for your situation.

Guidelines for custom server control developers

As a developer of a custom control, you should follow the general best practices for asp.net application pages and controls and security in the. NET Framework. In many cases, users of custom server controls may not understand the details or security implications of all implementations. However, you should plan this by following the established security conventions and clearly stating all the permissions that the component needs to work properly. You can get from ASP.net Web site security, the. NET Framework Developer's Guide, the basic concept of security, and the "Patterns and Practices Web site" (Patterns and Practices website) To initiate a survey of common security issues and solutions.

After you design and implement a custom Web server control, you must determine how to provide the component to the user. There are two common methods of providing: as an assembly or as a community component. If you provide a component as an assembly, you should sign the assembly (also known as a strong name signature). A signature provides a unique identity for an assembly that other software can use to identify and explicitly reference the assembly. At the same time, this approach can provide additional benefits by using assembly programming to describe these benefits in detail.

If you are providing a component as a community component with an automated installation process, you should sign the component in an encrypted manner. A signature can help verify that the data originates from a specific party by creating a digital signature that is unique to a particular party. One way to create a community component for Visual Studio 2005 is to install the program with Visual Studio content and create a. vsi file that you can sign.

The following provides some security guidelines to consider when developing custom server control components. This list may not be comprehensive enough, but you can start a survey from here:

Provides instructions on how to use these controls, along with custom server controls, as well as requirements for the resources and permissions required for these controls to function correctly.

Digitally sign a component

If the custom control is packaged as an assembly, the Assembly is signed with a strong name. For more information, see Creating and Using Strong-named assemblies. If you use an automatic installer, such as the 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 work with Visual Studio content Install the program.

Follow the best practices for exception management in your code

If you want page developers to add custom controls to the toolbox of the visual designer, drag them onto the design surface, access their properties and events in the property browser, and consider design-time security in addition to Run-time security. For more information, see Securing custom control designer components.

Learn about the highest threats to WEB application pages and controls, including code injection, information disclosure, session hijacking, identity spoofing, parameter manipulation, and network monitoring. To do this, you should complete a threat modeling analysis of your components before deployment.