Security issues that must be addressed by Visual Basic. NET and Visual C #. NET programmers (2)

Http://faq.lvjiyong.com/category/dotnet/3/
Other resources
In addition to the content described in the preceding overview, there are many other options to choose from. The following topics detail code access security:

Introduction to Code Access Security)
Code Access Security)
Security Namespaces in Visual Studio)
Web Applications
This solution protects your server against malicious code attacks and prevents data from being damaged. You can use multiple methods to protect your servers.

By disabling the dynamic Discovery Function of XML Web services, users are prohibited from searching for and running your XML Web services.
Before allowing a user to access the server, use authentication to verify the user's identity.
By using the ASPNET Process Identity, you can better adjust the resources you can use.
Each method is described in detail below.

Dynamic discovery
Dynamic discovery is a function of the. NET Framework. It allows Web browsers to search for XML Web services running on servers. After finding the XML Web service, you can call the XML Web services method. Although dynamic discovery provides powerful functions for users, it also brings potential security risks to servers. In most cases, you do not need to enable the dynamic discovery function. When installing the. NET Framework, it is found that it is disabled by default. This does not mean that the XML Web services is unavailable, but only the directory where the server will not provide available services. The client can still use XML Web services, but you need to provide the exact location of the service to it.

Warning after dynamic discovery is disabled, you need to send the XML Web services location to the client.
On the Deployment Server, there are two items that can control the XML Web services Discovery Function. The first item (machine. config file) controls the overall server discovery function. The machine. config file is an XML file that contains settings for Web applications on the control server. It is located in the \ % windows % \ Microsoft. NET \ Framework \ Version \ Config folder. This file contains an element that is commented out by default. To enable the discovery feature, you need to delete these annotation characters. You also need to use the ASPNET account to run the application, as described in "ASPNET Process Identity" in the following section.

<! -- <Add verb = "*" path = "*. vsdisco"
Type = "System. Web. Services. Discovery. DiscoveryRequestHandler,
System. Web. Services, Version = 1.0.3300.0, Culture = neutral,
PublicKeyToken = b03f5f7f11d50a3a "validate =" false "/> -->
The second is a file found. The found file can be the default found file (default. vsdisco), or the XML Web services-specific found file. It is an XML file that contains information about the location of the XML Web services file.

To discover specific XML Web services on the client, you must enable the Discovery Function in the machine. config file and create and deploy application discovery files. The file is an XML file that only lists paths that do not contain XML Web services. An example is provided below. For a complete description of creating and Deploying this file, see Deploying XML Web Services in Managed Code ).

<? Xml version = "1.0" encoding = "UTF-8"?>
<DynamicDiscovery xmlns = "urn: schemas-dynamicdiscovery: disco.2000-03-17">
<Exclude path = "_ vti_cnf"/>
<Exclude path = "_ vti_pvt"/>
<Exclude path = "_ vti_log"/>
<Exclude path = "_ vti_script"/>
<Exclude path = "_ vti_txt"/>
<Exclude path = "Web References"/>
</DynamicDiscovery>
If your Deployment Server is installed with Visual Studio.. NET, the Web root folder will contain the default found file (default. vsdisco), the file is in Visual Studio.. NET. If the server contains this file and the discovery function is enabled in the machine. config file, all XML Web services on the server can be found. To disable XML Web services, delete the file.

Warning If Visual Studio. NET is installed on the Deployment Server, the default. vsdisco file should be deleted before the server is ready for use.
We recommend that you do not deploy XML Web services on a server with Visual Studio. NET installed. Visual Studio. NET installer adds files and users that can be used to your system. You can protect the security of systems that have installed Visual Studio. NET. However, if you do not need to install Visual Studio. NET on the Deployment Server, we recommend that you do not install Visual Studio. NET.
For more information about Enabling dynamic Discovery, see Enabling Discovery for an XML Web services (English) and Fine-Tuning Discovery Mechanisms (English ).

Identity verification, simulation, and delegation
By default, Web applications run in anonymous mode, that is, the application does not need any information about the user identity. This applies to sites that contain public information. If you want to control users who access applications or other resources, you need to add authentication to the application. Authentication is the process of identifying the user of the application and verifying whether the user has the right to access the application. ASP. NET supports multiple authentication methods. The most common methods are:

Anonymous users do not need to provide any identification information. This method is applicable to websites that contain public content. If you need to personalize your site, you can use cookies. For more information about how to use cookies in ASP. NET applications, see Introduction to Web Forms State Management ).
The form application provides you with a logon form, requiring you to provide logon information (such as name and password ). The form is sent back to the server, and the server compares the information with the data warehouse.
Basic identity authentication is configured using Internet Information Service (IIS). Most browsers support basic identity authentication. If enabled, the browser prompts the user to enter the name and password, and then uses Base64 encoding (this encoding is easy to decrypt) to send the information back to the ASP. NET application. This method requires that you have a Windows account. If you use SSL in addition to basic authentication, You can ensure the security of this authentication method. For more information about SSL support in ASP. NET, see Using Secure Sockets Layer ).
Brief authentication is configured using IIS and can be used on a server running Microsoft Windows 2000 or Windows XP. Simple authentication provides a higher password encryption level than basic authentication. This method requires that you have a Windows Account stored in Microsoft Active Directory.
Integrated Windows integrated Windows authentication is similar to Basic Authentication and brief authentication. The only difference is that the user's name and password are not transmitted back to the Web application. This method is especially applicable to the Intranet environment. It requires that you have a Windows Account and only Internet Explorer supports this method.
A certificate is a digital key installed on a computer. This key is required when a user attempts to access the server. The server then verifies the certificate in the domain or Active Directory. This method applies to applications that require high security and do not hesitate to manage certificates.
Passport Microsoft provides this centralized authentication service. Passport authentication applies to the following situations: when your Web site is used with other Passport sites, users can access all sites only once they log on; or you do not want to maintain the user database.
Authentication allows you to authorize the user of the application, but this is not enough to allow the user to access resources, such as files and databases. You can configure resources to make them available to specific users (rather than the Web application itself. In this case, you can use a simulation to allow users to access these resources. During the simulation, the server process runs with the authenticated user identity. When an application simulates and queries a database, the database application determines that the query comes from the user rather than the server when processing the query. As shown in the following example, you can enable simulation by setting the impersonate attribute of the identity element in the Web. config file of the application. The Web. config file is created as part of each Web application project.

<Identity impersonate = "true">
Further than the simulation, a delegate uses a user ID to access remote resources (other computers. As shown in the following table, not all authentication methods support delegation.

Support delegation not support delegation
Basically anonymous
Windows integration Overview
Certificate Passport
Form

For more information about how to select and implement Authentication methods, see Authentication in ASP. NET:. NET Security Guidance ). For more information about Web Application Security, see Web Application Security at Run Time ).

ASPNET process ID
When a Web application starts running on the server, it does not run as you log on as the Web application author. Instead, it runs like logging on with a Windows User Account defined on the server. This account (also known as an identity) can be one of the following three accounts: The ASPNET identity, the SYSTEM identity, or the custom identity. This identifier is specified in the machine. config XML file (located in the \ % windows % \ Microsoft. NET \ Framework \ Version \ Config folder on the server. The following is a simplified example of the three configuration methods for this element. The element in the file has several attributes, which are not displayed in this example.

<! -- Select the ASPNET id -->
<System. web>
<ProcessModel enable = "true" username = "MACHINE" password = "AutoGenerate"/>
</System. web>

<! -- Select SYSTEM id -->
<System. web>
<ProcessModel enable = "true" username = "SYSTEM" password = "AutoGenerate"/>
</System. web>

<! -- Select a custom id -->
<System. web>
<ProcessModel enable = "true" username = "domain \ user" password = "pwd"/>
</System. web>
ASPNET is the default identifier selected when the machine. config file is installed with the. NET Framework. The ASPNET account is a member of the Users Group. By default, the Users Group has only the minimum permissions. The ASPNET account also has several other permissions, including all permissions on ASP. NET and Windows temporary directories.

If you change the identity to SYSTEM, the application runs under the SYSTEM identity, which has the permissions of the Administrators group. The SYSTEM account can access almost all resources on the server.

Warning if the server runs under the SYSTEM identifier, the risk of malicious code attacks and data destruction is extremely high.
To use a custom identity, you must create an account and configure its permissions in a specific way. For more information about creating a custom identity, see Authentication in ASP. NET:. NET Security Guidelines ).

By default, several system resources are unavailable to the ASPNET account. The following describes common restrictions and solutions. We recommend that you use the ASPNET account and the solution, instead of running the application under the SYSTEM Identity.

File resources can access the access control list (ACL) of each file and folder through Windows Resource Manager to adjust the file and folder permissions granted to the ASPNET account. Changes to the ACL of ASPNET are not automatically propagated through deployment. For example, you may allow the ASPNET account to write to the c: \ picture.bmp file on the development computer. When an application is deployed, the application runs on another computer, which also has an ASPNET account. You need to add write permissions to the c: \ picture.bmp file on the deployment computer for the ASPNET account on the deployment computer. Fortunately, you can use custom operations in a deployment project to change the ACL, but you must keep track of the changes you have made.
The Event Log ASPNET account can add entries to existing logs, but cannot create a new event log category. In this case, you can enable the simulation when using the ASPNET account to create a new event log category. The simulated identity must have sufficient permissions to create an event log category. If the event logs required by the application can be specified before use, the logs can be created by the deployment project.
To access Directory services and Active Directory, You need to simulate and delegate them, or pass specific security creden。 to the DirectoryEntry object. If you choose to pass specific security creden。 to the DirectoryEntry object, make sure that this information is properly stored.
The performance counter ASPNET account can only write but cannot read the performance counter, and cannot create a new performance counter category. In this case, you can enable the simulation when using the ASPNET account to create a new performance counter category. The simulated ID must have sufficient permissions to create a performance counter category. If the performance counters required by the application can be specified before they are put into use, you can create these performance counters by the deployment project.
Protects file resources during runtime under the ASPNET identity
Note: The instructions in this section apply to systems that run the NTFS file system. If your server runs a FAT32 file system, see the file system instructions file for information on file security protection.
By default, the ASPNET account only has read and execution permissions for the Users Group. If a Web application needs to write or create a new file, you can authorize a specific file or folder by modifying the access control list (ACL. To access the ACL of a file, right-click the file in Windows Resource Manager and select the "properties" and "security" tabs. It is best to modify the ACL of a specific file instead of adding general permissions to the ASPNET account. The most commonly used permissions include:

Read-the read permission is required for data files and executable files.
Write-the write permission is required for data files updated by the application.
Run-in a Web application, the. asmx file is an executable file.
Create-to create a file, you must add the creation permission for the folder in which you want to create the file.
These permissions apply:

File
Folder
Warning do not allow simultaneous execution and write or creation permissions on the same file or directory. In this case, the user may try to write malicious code into the file and then execute it.
Here are some tips for simplifying the authorization process:

According to the permissions required for files in the application, the files are placed in different directories. For example, if you only store read/execution files in a directory, you only need to set these permissions for a directory, instead of setting permissions for each file separately. Consider creating directories for read/execute, read/write, and read/create permissions in the application.
An application can contain data files that are empty during deployment and the Code required to create files when the application is run for the first time. This requires you to add the creation permission for the Directory, which is a high security setting. To avoid adding code to create a new empty file, consider providing an empty file to the application during deployment. In this way, you only need to add the write permission to the file, instead of adding the create permission to the directory.
When developing an application, you add permissions to files and directories on the development computer to precisely adjust the security level of the application. Unfortunately, the ACL will not be passed to the corresponding file on the deployed computer. To plan to pass these ACLs, remember the following:

You can use custom operations in the deployment package to change the ACL. For more information, see Custom Actions ).
You can use third-party tools to track and find changes.
You may need to confirm each setting with the system administrator. You need to record the reason for the change and why it is necessary to change the settings for the purpose.
Debug with the ASPNET identifier
When debugging XML Web services, if the ASPNET identifier is defined in the machine. config file, this identifier is used to call the XML Web services. By default, the ASPNET identity is not a member of the Debugger Users Group (see the "Visual Studio. "). Therefore, you cannot access the XML Web services Code during debugging. To debug XML Web services, open the code of XML Web services and set a breakpoint.

We recommend that you debug your computer instead of deploying it. This will be discussed in the next section "security mechanisms in the Visual Studio. NET development environment.

For more information, see ASP. NET Process Identity and ASP. NET Impersonation ).

Security Mechanism in Visual Studio. NET development environment
In addition to protecting server security, it also protects development computers from malicious code attacks and data damages. You can use multiple mechanisms in the development environment to protect the security of the Development Server:

VS Developers and Debuggers add these two account groups When Visual Studio. NET is installed. The VS Developers group has the necessary file, share, and IIS permissions to create and develop Web applications on the server. The Debuggers group can debug processes on a specific computer (local or remote. Both groups are users with high permissions on the server and can access most resources. For more information, see Web Application Security at Design Time in Visual Studio ).

It is recommended that you Debug on the Testing Computer (rather than deploying the computer. If debugging must be performed on the Deployment Server, install only the remote debugging component and uninstall it. Debug the server offline. For more information, see Introduction to Web Application Debugging ).

For most applications, you only need to install the. NET Framework on the server. If Visual Studio. NET or Visual Studio. NET Server Components are installed on the deployed computer, both the VS Developers group and the Debuggers group will appear on the deployed computer. You must restrict VS Developers members and Debugger users. In addition, dynamic discovery may need to be disabled.

Warning it is strongly recommended that you do not install Visual Studio on the Deployment Server.
The copy project function of Visual Studio. NET includes the options for deploying an application using the configuration file (Web. config). This configuration file is different from the configuration file used in development. Debugging may be enabled for the development file. After deployment, you can check the call stack when an exception is thrown. We recommend that you deploy a configuration file that does not allow debugging.

Summary
Resource Security Protection is a process involving multiple technologies and the entire development cycle. By carefully designing, implementing, testing, and deploying applications, you can create very secure applications. Security technologies provided by ASP. NET, operating systems, and Web browsers can be used to protect the security of applications.