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:

• Do not work with unfamiliar code or code you do not understand the security implications of. For community components, it is recommended that you read available publisher information and determine whether components are signed. For more information, see How to: Package Community Components to Use the Visual Studio Content Installer.

• Consider not just the run-time security of the control but also its design-time security. For more information, see Securing Custom Control Designer Components.

• When possible, work with custom controls in strongly-named assemblies and with trusted publishers. For more information, see How to: Determine an Assembly's Fully Qualified Name.

• Run ASP.NET Web applications that include imported controls in a least-privileged account. For more information about running ASP.NET processes with an identity that has minimal permissions, see Configuring ASP.NET Process Identity. In an IDE like Visual Studio 2005 or Visual Web Developer Express, run applications as a normal user and not as an administrator unless you need to perform administrative tasks. For more information, see User Rights and Visual Studio.

• Review operating system security and Windows access control lists (ACLs) on the server that hosts the custom server controls. For example, you should ensure that the ASP.NET process runs with an identity that has only minimal permissions required to run your application so that a security breach by a custom server control has minimal impact on other hosted applications. For more information, see Configuring ASP.NET Process Identity. Additionally, review the permissions of custom server controls and make sure they adhere to file and folder permissions that the identity of your ASP.NET Web application must have to function properly. For more information, see ASP.NET Required Access Control Lists (ACLs).

• Use code access security to restrict the resources the Web application (with custom server controls) can access and the privileged operations it can perform. For more information, see ASP.NET Code Access Security.

• Use the .NET Framework Configuration tool (Mscorcfg.msc) to manage and configure assemblies in the global assembly cache and to adjust code access security policy. Because Mscorcfg.msc is intended to help advanced administrators perform tasks related to configuring applications, work with your system administrator to determine whether using it is appropriate for your situation. For more information, see .NET Framework Configuration Tool (Mscorcfg.msc).

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.

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:

• Provide instructions with your custom server controls about how to use them, and expectations of resources and permissions that they need to function correctly.

• Digitally sign your components. If you package your custom control as an assembly, sign the assembly with a strong name. For more information, see Creating and Using Strong-Named Assemblies. If you use an automated installer such as Visual Studio Content Installer, you should still sign your components. For more information, see How to: Package Community Components to Use the Visual Studio Content Installer.

• Follow best practices for exception management in your code. For more information, see Chapter 10 on the Patterns and Practices Web site, for example.

• If you intend page developers to add your custom controls to the visual designer's toolbox, drag them onto the design surface, and access their properties and events in the property browser, you should consider design-time security in addition to run-time security. For more information, see Securing Custom Control Designer Components.

• Understand the top threats to Web application pages and controls, including code injection, information disclosure, session hijacking, identity spoofing, parameter manipulation, and network eavesdropping. To this end, complete a threat-modeling analysis of your components before deployment. For more information, see the Threat Modeling Web Applications topic at the Patterns and Practices Web site.

Concepts

Other Resources