ASP. NET protects custom server controls and asp.net controls

ASP. NET protects custom server controls and asp.net controls

Custom server controls are a way to extend the functions 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 develop custom ASP. NET Server controls.

IDE (such as Microsoft Visual Studio 2005) Simplifies the use and development of custom controls. However, no matter which IDE is used, the security rules listed below apply.

For general information about ASP. NET Web Application Security, see ASP. NET Web Application Security.

Custom server control user rules

You can use custom server controls in Web applications in multiple ways. For example, you can directly store source code files in the App_Code folder of Web applications and use controls from Global Assembly Cache, you can also use the Community components installed by an automatic installation program, such as Visual Studio content installer. In all circumstances, preventive measures should be taken to prevent malicious code imports or code that has an unexpected but negative impact on the IDE and the server hosting components.

The following provides some security rules that users of custom server controls should consider. This list may not be comprehensive enough, but you can proceed with the investigation:

Do not use unfamiliar code or code that does not understand its security risks. For community components, we recommend that you read the available issuer information and determine whether the component is signed.

You should not only consider the runtime security of the control, but also the design security.

If possible, use the custom control in the strong name program and select a trusted publisher.

Use the least privileged account to run ASP. NET Web applications that include imported controls. For more information about running ASP. NET processes with the lowest privilege, see configure ASP. NET process identifiers. In an IDE such as Visual Studio 2005 or quick release of Visual Web Developer, unless you need to execute management tasks, do not run applications as administrators as normal users.

View the operating system security and Windows Access Control List (ACL) of the server hosting the custom Server Control ). For example, make sure that you run ASP with only the minimum permissions required to run the application. to minimize the impact of security vulnerabilities caused by custom server controls on other hosted applications.

In addition, view the permissions of custom server controls and ensure that they comply with the file and folder permissions. The ASP. NET Web application identity must have this permission to work properly.

Use code access security to restrict resources that can be accessed by Web applications (with custom server controls) and privileged operations that can be performed.

Use the. NET Framework Configuration tool (Mscorcfg. msc) to manage and configure the assembly in the Global Assembly Cache and adjust the code access security policy. Because Mscorcfg. msc is used to help senior administrators perform tasks related to application configuration, work with your system administrator to determine whether the tool meets your needs.

Guidelines for custom Server Control developers

As a developer of custom controls, you should follow the common best practices for security in ASP. NET application pages and controls and. NET Framework. In many cases, users of custom server controls may not understand the details or security risks of All implementations. However, you should plan this by following the established security conventions and clearly specifying all permissions required for the component to work normally. You can.. NET Website Security ,. NET Framework developer guide, basic security concepts, and security topics in Patterns and Practices Web site to investigate general security issues and solutions.

After the custom Web server control is designed and implemented, you must determine how to provide the component to the user. There are two common methods to provide: provided as an assembly or as a Community component. If a component is provided as an assembly, you must sign the Assembly (also known as a strong name signature ). The signature provides a unique identifier for the Assembly. Other software can use this identifier to identify the Assembly and explicitly reference the assembly. At the same time, this method provides other benefits, which are described in detail in assembly programming.

If a component is provided as a Community component with an automatic installation process, you should sign the component in encrypted mode. A signature can be used to create a unique digital signature for a specific party to verify whether the data is sent from 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 provides some security rules to consider when developing custom server control components. This list may not be comprehensive enough, but you can proceed with the investigation:

Provides instructions on how to use these controls along with custom server controls, as well as requirements on resources and permissions required for normal operation of these controls.

Digitally sign a component

If you package a custom control as an assembly, use a strong name to sign the assembly. For more information, see create and use an assembly with a strong name. If you use an automatic Installer (for example, 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 install programs using Visual Studio Content.

Best practices for exception management in code

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

Measure the test taker's knowledge about the top threats to Web application pages and controls, including code injection, information leakage, session hijacking, identity spoofing, parameter operations, and network listening. Therefore, Threat modeling and analysis of components should be completed before deployment.