Securing Custom Server Controls

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

An IDE such as Microsoft Visual Studio 2005 simplifies custom control use as well as development. However, the security guidelines listed below apply regardless of what 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

There are numerous ways for you to use custom server controls in a Web application; for example, you can place source code files directly in your Web application's App_Code folder, use controls from a global assembly cache, or use community components installed through an automated installer such as the Visual Studio Content Installer. In all cases, you should take precautions against importing malicious code or code that has unintentional but undesirable impact on your IDE and the server hosting the components.

Some security guidelines to consider as a user of custom server controls are given below. This list is not intended to be comprehensive, but to provide a starting point for investigation:

Guidelines for Developers of Custom Server Controls

As a developer of custom controls, you should follow general best practices for security in ASP.NET application pages and controls and in the .NET Framework. In many cases, the users of your custom server controls might not be aware of all the implementation details or security implications. You should plan for this by following established security conventions and clearly calling out all permissions needed for you components to function. You can start your investigation of general security issues and resolutions for Web applications with Securing ASP.NET Web Sites, the .NET Framework Developer's Guide Key Security Concepts, and with the security topics at the Patterns and Practices Web site.

After you design and implement your custom Web server controls, you must decide how to deliver your components to users. Two common methods of delivery are as an assembly or as a community component. If you deliver your components as an assembly, you should sign your assembly (also called strong-name signing). Signing gives your assembly a unique identity that other software can use to identify and explicitly refer to it. There are also other benefits, as detailed in Programming with Assemblies.

If you deliver your components as a community component with an automated installation procedure, then you should sign your components cryptographically. Signing helps verify that the data originates from a specific party by creating a digital signature that is unique to that party. One way to create community components for use with Visual Studio 2005 is to use the Visual Studio Content Installer and create .vsi files which can be signed. For more information, see How to: Package Community Components to Use the Visual Studio Content Installer and How to: Package Components to Use the Visual Studio Content Installer.

Some security guidelines to consider when you develop custom server control components are given below. This list is not intended to be comprehensive, but to provide a starting point for investigation:

See Also

Concepts

Securing Custom Control Designer Components

Other Resources

Patterns and Practices Web site

Creating and Using Strong-Named Assemblies

Programming with Assemblies

ASP.NET Web Application Security

Developing Custom ASP.NET Server Controls