外文文献翻译 - Web 应用程序的基本安全做法

毕业设计(论文) 外文文献翻译

专

业

计算机科学与技术

学生姓名 班学

级 号

指导教师

信息工程学院

中文译文

Web 应用程序的基本安全做法

即使您对应用程序安全性的体验和了解非常有限，也应采取一些基本措施来保护您的 Web 应用程序。以下各部分提供了适用于所有 Web 应用程序的最低安全性准则。常规 Web 应用程序安全性建议；使用最少特权运行应用程序；了解您的用户；防止恶意用户的输入；安全地访问数据库；创建安全的错误消息；保证敏感信息的安全；安全地使用 Cookie；防止拒绝服务威胁。 1.常规 Web 应用程序安全性建议；

如果恶意用户可以使用简单方法进入您的计算机，即使是最精心设计的应用程序安全性也会失败。常规 Web 应用程序安全性建议包括以下内容：经常备份数据，并将备份存放在安全的场所；将您的 Web 服务器放置在安全的场所，使未经授权的用户无法访问它、关闭它、带走它，等等。使用 Windows NTFS 文件系统，不使用 FAT32。NTFS 的安全性比 FAT32 高得多。使用不易破解的密码，保护 Web 服务器和同一网络上的所有计算机的安全。遵循用于确保 Internet 信息服务 (IIS) 安全的最佳做法。关闭任何不使用的端口并关闭不使用的服务。运行监视网站通信量的病毒检查程序。使用防火墙。了解和安装来自 Microsoft 和其他供应商的最新安全更新。使用 Windows 事件日志记录，并且经常检查这些日志，以查找可疑活动。这样的活动包括：反复尝试登录您的系统，以及向您的 Web 服务器发出数量巨大的请求。

2.使用最少特权运行应用程序 当您的应用程序运行时，它运行在一个具有本地计算机（还可能是远程计算机）的特定特权的上下文中。有关配置应用程序标识的信息，请参见 配置 ASP.NET 进程标识。若要以最少特权运行，请遵循以下准则： 不要以系统用户（管理员）身份运行应用程序。在具有最少实用特权的用户上下文中运行应用程序。 设置应用程序所需的所有资源上的权限（ACL 或访问控制列表）。使用最严格的设置。例如，如果在您的应用程序中是可行的，则将文件设置为只读。有关 ASP.NET 应用程序标识所需的最少 ACL 权限的列表，请参见 ASP.NET 必需的访问控制列表 (ACL)。将您的 Web 应用程序的文件保存在应用程序根目录下的一个文件夹中。不要让用户指定在应用程序中进行文件访问的路径。这样有助于防止用户访问服务器的根目录。

3.了解您的用户

在许多应用程序中，用户有可能不必提供凭据即可访问网站。如果是这样，则您的应用程序通过在预定义用户的上下文中运行即可访问资源。默认情况下，此上下文是 Web 服务器上的本地 ASPNET 用户（Windows 2000 或 Windows XP）或 NETWORK SERVICE 用户 (Windows Server 2003)。若要仅允许已授权用户进行访问，请遵循以下准则： 如果您的应用程序是 Intranet 应用程序，则将其配置为使用 Windows 集成安全性。这样，用户的登录凭据就可以用于访问

1

资源。如果您需要从用户收集凭据，则使用其中一种 ASP.NET 身份验证策略。有关示例，请参见 ASP.NET Forms 身份验证概述。

4.防止恶意用户的输入

通常，决不假定从用户获得的输入是安全的。对恶意用户来说，从客户端向您的应用程序发送潜在危险的信息是很容易的。若要帮助防止恶意输入，请遵循以下准则： 在窗体中，筛选用户输入以查找 HTML 标记，其中可能包含脚本。有关详细信息，请参见 如何：通过对字符串应用 HTML 编码在 Web 应用程序中防止脚本侵入。决不回显（显示）未经筛选的用户输入。在显示不受信任的信息之前，对 HTML 进行编码以将潜在有害的脚本转换为显示字符串。类似地，决不将未经筛选的用户输入存储在数据库中。如果要接受来自用户的一些 HTML，则手动筛选它。在您的筛选器中，显式定义将要接受的内容。不要创建一个试图筛选出恶意输入的筛选器；因为预料到所有可能的恶意输入是非常困难的。不要假定您从标头（通常通过 Request 对象）获得的信息是安全的。对查询字符串、Cookie 等采取安全措施。注意，浏览器向服务器报告的信息（用户代理信息）可以被假冒（如果此信息在您的应用程序中相当重要）。如有可能，不要将敏感信息（如隐藏字段或 Cookie）存储在可从浏览器访问的位置。例如，不要将密码存储在 Cookie 中。

5.安全地访问数据库

数据库通常具有它们自己的安全性。Web 应用程序安全性的一个重要方面是设计一种应用程序安全地访问数据库的方式。请遵循这些指导： 使用数据库的内在安全性来限制可以访问数据库资源的人员。确切的策略取决于您的数据库和应用程序： 如果在您的应用程序中切实可行，请使用 Windows 集成安全性以便只有 Windows 授权的用户才能访问数据库。集成安全性比使用 SQL Server 标准安全性更安全。如果您的应用程序使用匿名访问，请创建具有非常有限的权限的单个用户，并以此用户身份连接来执行查询。不要通过串联涉及用户输入的字符串创建 SQL 语句。相反，创建参数化查询并使用用户输入设置参数值。 如果您必须将用户名和密码存储在某个位置以用作数据库登录凭据，请安全地存储它们。如果可行，请对它们进行加密或计算哈希值。

6.创建安全的错误消息 如果您不小心，恶意用户就可以从应用程序显示的错误消息推断出有关您的应用程序的重要信息。请遵循这些指导： 不要编写会回显可能对恶意用户有用的信息（例如用户名）的错误消息。将应用程序配置为不向用户显示详细错误。如果为进行调试而要显示详细错误消息，请先检查该用户是否为 Web 服务器的本地用户。使用customErrors 配置元素控制谁可以查看服务器发出的异常。对于容易发生错误的情况（如数据库访问）创建自定义错误处理方式。

7.保证敏感信息的安全 “敏感信息”是需要保密的任意信息。密码或加密密钥即是典型的敏感信息。如果恶意用户可以获得敏感信息，则该信息保护的数据将受到威胁。请遵循这些

2

指导： 如果您的应用程序在浏览器和服务器之间传输敏感信息，请考虑使用安全套接字层 (SSL)。使用受保护的配置来确保配置文件（如 Web.config 或 Machine.config 文件）中敏感信息的安全。如果您必须存储敏感信息，即使是以您认为人们将无法看到它的形式（如在服务器代码中）进行保存，也不要将它保存在网页中。使用 System.Security.Cryptography 命名空间中提供的强加密算法。

8.安全地使用Cookie

为了让用户特定的信息保持可用，Cookie 是一种容易而有用的方法。但是，由于 Cookie 会被发送到浏览器所在的计算机，因此它们容易被假冒或用于其他恶意用途。请遵循这些指导： 不要将任何关键信息存储在 Cookie 中。例如，不要将用户的密码存储在 Cookie 中，即使是暂时存储也不要这样做。作为一项原则，不要在 Cookie 中存储任何敏感信息。而是在 Cookie 中保存对信息在服务器上的位置的引用。将 Cookie 的过期日期设置为可以设置的最短时间。尽可能避免使用永久的 Cookie。考虑对 Cookie 中的信息加密。考虑将 Cookie 的 Secure 和 HttpOnly 属性设置为 true。

9.防止拒绝服务威胁

恶意用户危害您的应用程序的一种间接方式是使其不可用。恶意用户可以使应用程序太忙而无法为其他用户提供服务，或者仅仅使应用程序出现故障。请遵循这些指导： 关闭或释放您使用的任何资源。例如，在使用完毕后，始终关闭数据连接和数据读取器，而且始终关闭文件。使用错误处理机制（例如，try/catch 块）。包含 finally 块，以便万一失败就可以在其中释放资源。将 IIS 配置为使用调节，这样可以防止应用程序消耗过多的 CPU。 在使用或存储用户输入之前，测试它的大小限制。对数据库查询设置大小保护措施，以防止大型查询耗尽系统资源。 如果文件上载是您的应用程序的一部分，则对它们的大小加以限制。还可以使用 RequestLengthDiskThreshold 属性来减少大型上载和窗体发布所需的内存开销。

3

英文原文

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 that 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 Denial-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 keep 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 of 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 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 within 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 application 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 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 of specifying a path for any file access in your application. This helps prevent users from getting access to the root of your server.

4

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 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 restrict access to users who are authenticated, follow these guidelines: If your application is an intranet application, configure it to use Windows Integrated security. This way, the user's 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. 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 user 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 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 anticipate 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 case 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 designing 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 security 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 create SQL statements by concatenating

5

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. 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 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 customErrorsconfiguration 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 sensitive 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 Secure 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 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 available. However, because cookies are sent to the browser's 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 user's password in a cookie, even temporarily. As a rule, do not store any sensitive 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 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

6

making it unavailable. The malicious user can keep the application too busy to service other users, or if nothing 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 which 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.

7

本文来源：https://www.bwwdw.com/article/0y7x.html