1、 外文文献翻译 英文原文 Basic Security Practices for Web Applications Even if you have limited experience with and knowledge of application security, there are basic measures that you should take to help protect your Web applications. The following sections in this topic provide minimum-security guidelines tha
2、t apply to all Web applications.General Web Application Security Recommendations；Run Applications with Minimum Privileges ；Know Your Users； Guard Against Malicious User Input；Access Databases Securely；Create Safe Error Messages；Keep Sensitive Information Safely；Use Cookies Securely；Guard Against Den
3、ial-of-Service Threats. 1. General Web Application Security Recommendations Even the most elaborate application security can fail if a malicious user can use simple ways to gain access to your computers. General Web application security recommendations include the following: Back up data often and k
4、eep your backups physically secure.Keep your Web server physically secure so that unauthorized users cannot gain access to it, turn it off, physically steal it, and so on.Use the Windows NTFS file system, not FAT32. NTFS offers substantially more security than FAT32. Protect the Web server and all o
5、f the computers on the same network with strong passwords.Follow best practices for securing Internet Information Services (IIS). Close any unused ports and turn off unused services.Run a virus checker that monitors site traffic.Use a firewall.Learn about and install the latest security updates from
6、 Microsoft and other vendors.Use Windows event logging and examine the logs frequently for suspicious activity. This includes repeated attempts to log on to your system and excessive requests against your Web server. 2. Run Applications with Minimum Privileges When your application runs, it runs wit
7、hin a context that has specific privileges on the local computer and potentially on remote computers. For information about configuring application identity, see Configuring ASP.NET Process Identity.To run with the minimum number of privileges needed, follow these guidelines: Do not run your applica
8、tion with the identity of a system user (administrator).Run the application in the context of a user with the minimum practical privileges. Set permissions (ACLs, or Access Control Lists) on all the resources required for your application. Use the most restrictive setting. For example, if practical
9、in your application, set files to be read-only. For a list of the minimum ACL permissions required for the identity of your ASP.NET application, see ASP.NET Required Access Control Lists (ACLs).Keep files for your Web application in a folder below the application root. Do not allow users the option
10、of specifying a path for any file access in your application. This helps prevent users from getting access to the root of your server. 3. Know Your Users In many applications, it is possible for users to access the site without having to provide credentials. If so, your application accesses resource
11、s 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 restrict access to users who are authenticated, follow these guidelines: If your application is an intra
12、net application, configure it to use Windows Integrated security. This way, the users login credentials can be used to access resources.If you need to gather credentials from the user, use one of the ASP.NET authentication strategies. For an example, see the ASP.NET Forms Authentication Overview. 4.
13、 Guard against Malicious User Input As a general rule, never assume that input you get from users is safe. It is easy for malicious users to send potentially dangerous information from the client to your application. To help guard against malicious input, follow these guidelines: In forms, filter us
14、er input to check for HTML tags, which might contain script. For details, see How to: Protect Against Script Exploits in a Web Application by Applying HTML Encoding to Strings.Never echo (display) unfiltered user input. Before displaying untrusted information, encode HTML to turn potentially harmful
15、 script into display strings.Similarly, never store unfiltered user input in a database.If you want to accept some HTML from a user, filter it manually. In your filter, explicitly define what you will accept. Do not create a filter that tries to filter out malicious input； it is very difficult to an
16、ticipate all possible malicious input.Do not assume that information you get from the header (usually via the Request object) is safe. Use safeguards for query strings, cookies, and so on. Be aware that information that the browser reports to the server (user agent information) can be spoofed, in ca
17、se that is important in your application.If possible, do not store sensitive information in a place that is accessible from the browser, such as hidden fields or cookies. 5. Access Databases Securely Databases typically have their own security. An important aspect Web application security is designi
18、ng a way for the application to access the database securely. Follow these guidelines: Use the inherent security of your database to limit who can access database resources. The exact strategy depends on your database and your application: If practical in your application, use Windows Integrated sec
19、urity so that only Windows-authenticated users can access the database. Integrated security is more secure than using SQL Server standard security.If your application uses anonymous access, create a single user with very limited permissions, and perform queries by connecting as this user.Do not crea
20、te SQL statements by concatenating strings that involve user input. Instead, create a parameterized query and use user input to set parameter values. If you must store a user name and password somewhere to use as the database login credential, store them securely. If practical, encrypt or hash them.
21、 For details, see Encrypting and Decrypting Data. 6. Create Safe Error Messages If you are not careful, a malicious user can deduce important information about your application from the error messages it displays. Follow these guidelines: Do not write error messages that echo information that might
22、be useful to malicious users, such as a user name.Configure the application not to show detailed errors to users. If you want to display detailed error messages for debugging, check first that the user is local to the Web server. For details, see How to: Display Safe Error Messages.Use the customErr
23、orsconfiguration element to control who can view exceptions from the server.Create custom error handling for situations that are prone to error, such as database access. 7. Keep Sensitive Information Safely Sensitive information is any information that you need to keep private. A typical piece of se
24、nsitive information is a password or an encryption key. If a malicious user can get to the sensitive information, then the data protected by the secret is compromised. Follow these guidelines: If your application transmits sensitive information between the browser and the server, consider using Secu
25、re Sockets Layer (SSL). Use Protected Configuration to secure sensitive information in configuration files such as the Web.config or Machine.config files. For more information, see Encrypting Configuration Information Using Protected Configuration.If you must store sensitive information, do not keep
26、 it in a Web page, even in a form that you think people will not be able to view (such as in server code).Use the strong encryption algorithms supplied in the System Security Cryptography namespace. 8 . Use Cookies Securely Cookies are an easy and useful way to keep user-specific information availab
27、le. However, because cookies are sent to the browsers computer, they are vulnerable to spoofing or other malicious use. Follow these guidelines: Do not store any critical information in cookies. For example, do not store a users password in a cookie, even temporarily. As a rule, do not store any sen
28、sitive information in a cookie that. Instead, keep a reference in the cookie to a location on the server where the information is located. Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible.Consider encrypting information in cookies. Consider
29、setting the Secure and HttpOnly properties on your cookies to true. 9. Guard against Denial-of-Service Threats An indirect way that a malicious user can compromise your application is by making it unavailable. The malicious user can keep the application too busy to service other users, or if nothing
30、 else can simply crash the application. Follow these guidelines: Close or release any resource you use. For example, always close data connections and data readers, and always close files when you are done using them.Use error handling (for example, try/catch blocks). Include a finally block in whic
31、h you release resources in case of failure.Configure IIS to use throttling, which prevents an application from using a disproportionate amount of CPU. Test size limits of user input before using or storing it.Put size safeguards on database queries to help guard against large queries using up system resources.You can also use the RequestLengthDiskThreshold property in to reduce the memory overhead of large uploads and form posts.
