Web 应用程序的基本安全实施策略


常规 Web 应用程序安全性建议


有些最基本的安全性建议也是最显然易见的。但是，如果恶意用户可以使用简单方法进入您的计算机，即使是最精心设计的应用程序安全性也会失败。

经常进行备份，并将备份存放在安全的场所。
将您的 Web 服务器计算机放置在安全的场所，这样，未经授权的用户就无法使用它、关闭它、带走它，等等。
使用 Windows NTFS 文件系统，不使用 FAT32。NTFS 的安全性比 FAT32 高得多。有关详细信息，请参见 Windows 文档。
使用不易破解的密码，确保 Web 服务器计算机和同一网络上的所有计算机的安全。
确保 IIS 的安全。有关详细信息，请参见 Microsoft 安全性 Web 站点 (http://microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/mcswebbp.asp) 上的文章“管理 Windows IIS Web 服务的安全性”。

关闭不使用的端口并关闭不使用的服务。
运行监视通信量的病毒检查程序。
建立并实施以下策略：禁止用户将其密码记在容易找到的位置。
使用防火墙。有关建议，请参见 Microsoft 安全性站点上的“核对清单：安装防火墙”。(http://microsoft.com/security/articles/firewall.asp)
了解和安装来自 Microsoft 和其他供应商的最新安全修补程序。例如，Microsoft 安全站点 (www.microsoft.com/security) 中有所有 Microsoft 产品的最新安全公告的列表。其他供应商也有类似站点。
使用 Windows 事件日志记录，并且经常检查这些日志，以查找可疑活动。这样的活动包括：反复尝试登录您的系统，以及向您的 Web 服务器发出数量巨大的请求。


使用最少特权运行应用程序



当您的应用程序运行时，它运行在一个具有本地计算机（还可能是远程计算机）的特定特权的上下文中。请遵循这些指导：

在具有最少实用特权的上下文中运行应用程序。默认情况下，在 IIS 5 版中，ASP.NET 应用程序运行在名为 ASPNET 的本地用户的上下文中。在 Windows Server 2003 上的 IIS 6 上，此帐户称为 NETWORK SERVICE。有关详细信息，请参见 ASP.NET 进程标识和配置 ASP.NET 进程标识。
不要在系统用户（管理员）的上下文中运行应用程序。
设置应用程序所需的所有资源上的权限（ACL 或访问控制列表）。使用最少的容许设置。例如，如果在您的应用程序中是可行的，则将文件设置为只读。有关详细信息，请参见 Windows 文档。
将您的 Web 应用程序的文件保存在应用程序根目录下的一个文件夹中。不要让用户指定在应用程序中进行文件访问的路径。这样有助于防止用户访问服务器的根目录。
不要使不需要调试 Visual Studio 应用程序的任何人成为“Debugger Users”（调试器用户）组的成员。此组具有比“VS Developers”（VS 开发人员）组更高的特权。有关详细信息，请参见添加调试器用户和配置 DCOM。


了解您的用户



在许多应用程序中，用户有可能不必提供凭据即可访问站点。如果是这样，则您的应用程序通过在预定义用户的上下文中运行即可访问资源。默认情况下，此上下文是 Web 服务器计算机上的本地 ASPNET 用户（Windows 2000 或 Windows XP）或 NETWORK SERVICE 用户 (Windows Server 2003)。

若要仅允许已授权用户进行访问，请遵循以下准则：

如果您的应用程序是 Intranet 应用程序，则将其配置为使用 Windows 集成安全性。这样，用户的登录凭据就可以用于访问资源。
如果您需要从用户收集凭据，则使用其中的一种 ASP.NET 身份验证策略。有关更多信息，请参见 ASP.NET 身份验证。有关示例，请参见简单 Forms 身份验证。


防止恶意用户的输入



通常，决不假定从用户获得的输入是安全的。对恶意用户来说，从客户端向您的应用程序发送潜在危险的信息是很容易的。若要防止恶意输入，请遵循以下准则：

在窗体中，筛选用户输入以查找 HTML 标记，其中可能包含脚本。有关详细信息，请参见在 Web 应用程序中防止脚本利用。
决不回显（显示）未经筛选的用户输入。在显示不受信任的信息之前，对 HTML 进行编码以将潜在有害的脚本转换为显示字符串。
类似地，决不将未经筛选的用户输入存储在数据库中。
如果要接受来自用户的一些 HTML，则手动筛选它。在您的筛选器中，显式定义将要接受的内容。不要创建一个试图筛选出恶意输入的筛选器；因为预料到所有可能的恶意输入是非常困难的。
不要假定您从标头（通常通过 Request 对象）获得的信息是安全的。对查询字符串、Cookie 等采取安全措施。注意浏览器向服务器报告的信息（用户代理信息）可以假冒，假如它在您的应用程序中是重要的。
如有可能，不要将敏感信息（如隐藏域或 Cookie）存储在可从浏览器访问的位置。例如，不要将用户名或密码存储在 Cookie 中。
注意 视图状态是以编码格式存储在隐藏域中的。默认情况下，它包含消息身份验证代码 (MAC)，以便页可以确定视图状态是否已被篡改。



创建安全的错误信息



如果您不小心，恶意用户就可以从应用程序显示的错误信息推断出有关您的应用程序的重要信息。请遵循这些指导：

不要编写会回显可能对恶意用户有用的信息（例如用户名）的错误信息。
将应用程序配置为不向用户显示详细错误。如果为进行调试而要显示详细错误信息，请先检查该用户是否为 Web 服务器的本地用户。有关详细信息，请参见显示安全的错误信息。
对于容易发生错误的情况（如数据库访问）创建自定义错误处理方式。


安全地保守秘密



“秘密”是指您不希望某人知道的信息。一个典型的秘密是密码或加密密钥。当然，如果恶意用户能够获得秘密，则由该秘密保护的数据会受到危害。请遵循这些指导：

如果您的应用程序在浏览器和服务器之间传输敏感信息，请考虑使用安全套接字层 (SSL)。有关如何实现 SSL 的详细信息，请参见 Microsoft 知识库文章 Q307267“HOW TO：在 Windows 2000 中使用安全套接字层来保障 XML Web services 的安全”(HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000)。
如果您必须存储秘密，即使是以您认为人们将无法看到它的形式（如在服务器代码中）进行保存，也不要将它保存在 Web 页中。
如果您对信息加密，请不要创建您自己的加密算法。请使用 Windows 数据保护 API (DPAPI)。


安全地使用 Cookie



为了让用户特定的信息保持可用，Cookie 是一种容易而有用的方法。但是，由于 Cookie 会被发送到浏览器所在的计算机，因此它们容易被假冒或用于其他恶意用途。请遵循这些指导：

不要将任何关键信息存储在 Cookie 中。例如，不要将用户的密码存储在 Cookie 中，即使是暂时存储也不要这样做。通常，不要将任何信息保存在 Cookie 中（一旦它被假冒，就会给您带来麻烦），而是在 Cookie 中保存对信息在服务器上的位置的引用。
设置 Cookie 的到期日期，使其有效期尽可能最短。如有可能，避免设置永久性 Cookie。
考虑对 Cookie 中的信息加密。


防止拒绝服务威胁



恶意用户危害您的应用程序的一种间接方式是使其不可用。恶意用户可以使应用程序太忙而无法为其他用户提供服务，或者仅仅使应用程序出现故障。请遵循这些指导：

关闭或释放您使用的任何资源。例如，在使用完毕后，始终关闭数据连接和数据读取器，而且始终关闭文件。
使用错误处理（例如，try-catch）。包含 finally 块，以便万一失败就可以在其中释放资源。
将 IIS 配置为使用进程调节，这样可以防止应用程序消耗过多的 CPU 时间。有关详细信息，请参见技术文章“使用 Internet Information Server 5.0 的新功能：第 1 部分”。
在使用或存储用户输入之前，测试它的大小限制。
对数据库查询的大小加以限制以确保安全。例如，在 Web 窗体页中显示查询结果之前，检查包含的记录数是否不合理。
如果文件上载是您的应用程序的一部分，则对它们的大小加以限制。您可以使用类似如下的语法在 Web.config 文件中设置限制（其中 maxRequestLength 值以千字节为单位）：
<configuration>
<system.web>
<httpRuntime maxRequestLength="4096" />
</system.web>
</configuration>

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>