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. 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.
Don't just consider the control's run-time security, but also its design-time security. For more information, see Securing custom control designer components.
If possible, use a custom control in a strong-named assembly and select a trusted publisher. For more information, see How to: Determine the fully qualified name of an assembly.
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. For more information, see User Rights and Visual Studio and user rights and Visual Studio.
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. For more information, see Configuring the ASP.net process identity. 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. For more information, see ASP.net required access control lists (ACLs).
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. 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 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. For more information, see the. NET Framework Configuration Tool (Mscorcfg.msc).