Basic security practices for Web applications (Visual Studio)

Even if youProgramSecurity experience and knowledge are very limited, and some basic measures should be taken to protect your web applications. The following sections of this topic provide the minimum security guidelines applicable to all web applications. Writing SecurityCodeAnd more details on best practices for ensuring application security, for more information, see writing security code and guidance from Microsoft patterns and practices, a book written by Michael Howard and David LeBlanc.

• Security suggestions for conventional Web Applications

• Run applications with minimal privileges

• Learn about your users

• Prevent malicious user input

• Securely access the database

• Create a secure error message

• Secure sensitive information

• Secure use of cookies

• Prevent Dos threats

Security suggestions for conventional Web Applications

If malicious users can access your computer in a simple way, even the most well-designed application security will fail. General Web Application Security recommendations include the following:

• Data is often backed up and stored in a safe place.

• Place your web server in a safe place, so that unauthorized users cannot access it, close it, take it away, and so on.

• Use Windows NTFS file system instead of FAT32. NTFS is much more secure than FAT32. For more information, see the Windows Help documentation.

• Use a password that is hard to crack to protect the security of the web server and all computers on the same network.

• Follow best practices to ensure the security of Internet Information Service (IIS. For more information, see "Windows Server techcenter for IIS" (Windows Server techcenter for IIS ).

• Disable any unused ports and disable unused services.

• Run the virus detection program that monitors website traffic.

• Use the firewall. For suggestions, see Microsoft firewall Guidelines (Microsoft firewall guidelines) on the Microsoft Security website ).

• Learn about and install the latest security updates from Microsoft and other vendors.

• Use Windows event logging and check these logs frequently to find suspicious activities. Such activities include repeated attempts to log on to your system and massive requests to your web server.

Run applications with minimal privileges

When your application is running, it runs in a context with specific privileges on the Local Computer (or remote computer. For information on configuring the application identity, see configuring the ASP. NET Process Identity.

To run with minimal privileges, follow these guidelines:

• Do not run applications as system users (administrators.

• Run the application in user context with minimal practical privileges.

• Set permissions (ACL or access control list) on all resources required by the application ). Use the strictest settings. For example, if it is feasible in your application, set the file to read-only. For a list of the minimum ACL permissions required for the ASP. NET application identity, see the required access control list (ACL) for ASP. NET ).

• Save your web application files in a folder under the application root directory. Do not allow users to specify the path for file access in the application. This helps prevent users from accessing the root directory of the server.

Learn about your users

In many applications, users may access the website without providing creden. If so, your application can access resources by running in the context of a predefined user. By default, this context is the local ASPnet user (Windows 2000 or Windows XP) or network service user (Windows Server 2003) on the web server ).

To allow access by only authorized users, follow these guidelines:

• If your application is an intranet application, configure it to use Windows integrated security. In this way, the user's login creden。 can be used to access resources.

• If you need to collect creden from a user, use one of the ASP. NET authentication policies. For examples, see ASP. NET Forms authentication overview.

Prevent malicious user input

Generally, it is never assumed that the input obtained from the user is safe. For malicious users, it is easy to send potentially dangerous information from the client to your application. To help prevent malicious input, follow these guidelines:

• In the form, filter user input to find HTML tags, which may contain scripts. For more information, see how to prevent script intrusion in Web applications by applying HTML encoding to strings.

• Do Not Display (Display) unfiltered user input. Encode HTML before displaying untrusted information to convert potentially harmful scripts into display strings.

• Similarly, user input that is not filtered is never stored in the database.

• If you want to accept some HTML from the user, manually filter it. In your filter, the content to be accepted is explicitly defined. Do not create a filter to filter out malicious input, because it is very difficult to predict all possible malicious input.

• Do not assume that youRequestObject. Take security measures for query strings and cookies. Note that the information reported by the browser to the server (User Proxy Information) can be spoofed (if this information is important in your application ).

• If possible, do not store sensitive information (such as hidden fields or cookies) in a location that can be accessed from a browser. For example, do not store passwords in cookies.

  Note:
  View status is stored in hidden fields in the encoding format. By default, it contains the message authentication code (MAC), so that the page can determine whether the view status has been tampered.

Securely access the database

Databases usually have their own security. An important aspect of Web Application Security is the design of a way for applications to securely access the database. Follow these guidelines:

• Use the inherent security of the database to restrict people who can access database resources. The exact policy depends on your database and application:

  • If it is feasible in your application, use Windows integrated security so that only Windows authorized users can access the database. Integration security is safer than SQL Server Standard Security.

  • If your application uses anonymous access, create a single user with very limited permissions and connect to the user for query.

• Do not create an SQL statement by concatenating strings that involve user input. Instead, create a parameterized query and use user input to set the parameter values.

• If you must store your usernames and passwords in a certain location for database login creden。, store them securely. If feasible, encrypt them or calculate the hash value. For more information, see encrypt and decrypt data.

For more information about secure data access, see ensure the security of the ADO. NET application.

Create a secure error message

If you are not careful, malicious users can infer important information about your application from the error message displayed by the application. Follow these guidelines:

• Do not write error messages that display information (such as user names) that may be useful to malicious users.

• Configure the application to not display detailed errors to users. If you want to display detailed error messages for debugging, check whether the user is a local user of the Web server. For more information, see How to: Display security error information.

• Use the customerrors configuration element to control who can view exceptions sent by the server.

• Create custom error handling methods for situations that are prone to errors (such as database access.

Secure sensitive information

"Sensitive Information" is any confidential information. Passwords or encryption keys are typical sensitive information. If a malicious user can obtain sensitive information, the data protected by this information is threatened. Follow these guidelines:

• If your application transmits sensitive information between the browser and the server, consider using Secure Sockets Layer (SSL ). For more information about how to use SSL to encrypt a website, seeArticleQ302.167, "How to: secure XML Web Services with Secure Sockets Layer in Windows 2000" (how to: Use the Secure Sockets Layer in Windows 2000 to ensure the security of XML Web Services ).

• Use protected configurations to ensure the security of sensitive information in configuration files (such as Web. config or machine. config files. For more information, see encrypt configuration information using protected configurations.

• If you must store sensitive information, do not store it in webpages even if you think people will not be able to see it (such as in server code.

• Use the strong encryption provided in the system. Security. cryptography namespaceAlgorithm.

Secure use of cookies

Cookie is an easy and useful method to keep user-specific information available. However, cookies are easily spoofed or used for other malicious purposes because they are sent to the computer where the browser is located. Follow these guidelines:

• Do not store any key information in cookies. For example, do not store users' passwords in cookies. Do not store passwords temporarily. As a principle, do not store any sensitive information in cookies. Instead, it saves a reference to the location of the information on the server in the cookie.

• Set the cookie expiration date to the shortest time that can be set. Avoid using permanent cookies whenever possible.

• Encryption of information in cookies is considered.

• Set the secure and HTTPOnly attributes of the cookieTrue.

Prevent Dos threats

An indirect way for malicious users to harm your applications is to make them unavailable. Malicious users can make applications too busy to provide services to other users, or simply cause application faults. Follow these guidelines:

• Close or release any resources you are using. For example, you can close the data connection and reader, and close the file after use.

• Use error handling mechanisms (for example,Try/catchBlock ). IncludeFinallyBlock to release resources in case of failure.

• Set IIS to use adjustment to prevent applications from consuming too much CPU.

• Test the size limit before using or storing user input.

• Set size protection measures for database queries to prevent large queries from consuming system resources.

• If file upload is part of your application, limit the size of the files. You can use the syntax similar to the following sample code to set limits in the web. config file (whereMaxrequestlengthValue in kilobytes ):

  Copy code

  <Configuration> <system. Web> 
  

You can also use the requestlengthdiskthreshold attribute to reduce the memory overhead required for large uploads and forms Publishing.