构建安全的 ASP.NET 应用程序

http://www.microsoft.com/china/msdn/archives/library/SecurityGuide/default.asp

重要术语
本节介绍本指南所用的一些重要安全术语。虽然本指南的“参考”部分提供了完整的术语词汇表，但您一定要非常熟悉下面这些术语：

• 身份验证明确识别应用程序的客户端，客户端包括最终用户、服务、进程或计算机。
• 授权。定义在应用程序中允许那些经过身份验证的客户端查看什么和执行什么操作。
• 安全通信。确保消息在通过网络传送后未被漏露、未被更改。
• 模拟。这是服务器应用程序用于代表客户端访问资源的技术。客户端的安全上下文供服务器执行访问检查使用。
• 委派。模拟的扩展形式，它允许一个代表客户端执行操作的服务器进程访问远程计算机上的资源。该功能由 Microsoft? Windows? 2000 及更高版本操作系统上的 Kerberos 在本地提供。常规模拟（例如，NTLM 提供的模拟）只允许一个网络跳跃。使用 NTLM 模拟时，在客户机与服务器之间使用一个跳跃，这就限制服务器在模拟时只能访问本地资源。
• 安全上下文。安全上下文是一个表示安全设置集合的常规术语，这些安全设置会影响进程或线程在安全方面的行为。一个进程的登录会话属性和访问令牌属性相结合，就形成了该进程的安全上下文。
• 标识。标识是能够唯一标明用户或者服务的一个特征。例如，它通常是显示名称，一般采用权限/用户名的形式。

原则
有若干重要原则适用于后面各章中提供的指导说明。下面摘要介绍这些原则：

• 采用最少权限的原则。运行脚本或执行代码的进程应当尽可能用权限最少的帐户运行，从而在危及进程安全时限制可能造成的破坏。如果恶意用户设法将代码注入某个服务器进程，那么授予该进程的权限会在很大程度上决定该用户可执行的操作类型。应当将需要更多信任（和更高权限）的代码分别隔离在不同的进程内。
  ASP.NET 小组有意识地决定运行拥有最少权限的 ASP.NET 帐户（使用 ASPNET 帐户）。但在 .NET Framework 的测试版中，ASP.NET 作为 SYSTEM 运行，这从本质上来说是一种较不安全的设置。
• 使用纵深防御。在应用程序中的每一层和每个子系统中设置检查点。检查点是网关守卫，它们确保只有经过身份验证和授权的用户能够访问下一个下游层。
• 不要信任用户输入。应用程序应该彻底验证所有用户输入，然后再根据用户输入执行操作。验证可能包括筛选特殊字符。针对用户意外地错误使用和某些人通过在系统中注入恶意命令蓄意进行攻击的情况，这种预防性措施对应用程序起到了保护作用。常见的例子包括 SQL 注入攻击、脚本注入和缓冲区溢出。
• 使用默认安全设置。开发人员往往仅仅为了使应用程序运行而使用安全性较低的设置。如果应用程序所需的功能使您不得不减小默认安全设置的安全级别或更改这些默认的安全设置，请在更改前测试更改所带来的后果并了解可能带来的隐患。
• 不要通过隐藏来保障安全。尝试使用让人迷惑的变量名来隐藏机密信息或将它们存储在不常用的文件位置，这些方法都不能提供安全保障。在“捉迷藏”游戏中，最好使用平台功能或使用已被证实可行的技术来保护数据。
• 在关口进行检查。您不必总是将用户的安全上下文传递到后端进行授权检查。通常，这种做法在分布式系统中并不是最佳选择。在关口检查客户端意思是在第一个身份验证点（例如，Web 服务器上的 Web 应用程序内）授予用户权限，并确定允许用户访问的资源和操作（可能由下游服务提供）。
  如果在关口设计可靠的身份验证和授权策略，就不必将原调用方的安全上下文一路委派到应用程序数据层。
• 假定外部系统是不安全的系统。如果外部系统不归您所有，不要假定有人为您保证安全。
• 减小表面区域。避免公开不需要公开的信息。如果公开这些信息，就可能进一步引起漏洞。同时，处理错误的方式一定要适当。向最终用户返回错误消息时，不要公开任何不需要公开的信息。
• 以安全的方式显示错误消息。如果应用程序失败，一定要保护好机密数据。同时，不要在错误消息中提供过于详细的数据，也就是不要提供任何有助于攻击者发现应用程序漏洞的详细信息。详细的错误信息应写入 Windows 事件日志。
• 不要忘记您的安全程度受最薄弱环节制约。考虑安全性时，应该将应用程序所有层的安全性都考虑在内。
• 禁用不使用的内容。您可以通过禁用应用程序不需要的模块和组件来去除一些潜在的攻击点。例如，如果应用程序不使用输出缓存，则应禁用 ASP.NET 输出缓存模块。这样，即使以后在该模块中发现安全漏洞，应用程序也不会受到威胁。