ASP.NET 应用程序安全设计原则

设计原则

有若干重要原则适用于后面各章中提供的指导说明。您应当学会这些原则并在自己的应用程序设计中予以应用：

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