ASP.NET 安全模型 Part.1（安全编程原则、理解安全级别）

       设计一个适当的安全策略是所有分布式应用程序的关键部分之一，对于暴露在因特网上的大型 Web 应用程序尤为如此。

       安全是 Web 应用程序的重要组成部分，开发伊始就应被纳入规划。通常采用如下几种机制：用户验证、授权、禁止访问敏感资源、保护服务器上存储的数据、保护网络上传输的数据。

       ASP.NET 用内置的一个提供基本安全功能的底层框架来满足这一需求。ASP.NET 的安全框架包括了用户验证和授权的类，也提供了在应用程序中处理已验证用户的类。它还有一组管理用户和角色的高级模型，允许编程访问或使用内置管理工具来进行管理。此外，.NET Framework 本身也提供了一系列基类，用来保证加密和数字签名过程中数据的机密性和完整性。

为何创建安全软件？

       .NET 和 ASP.NET 提供的安全框架非常强大，但必须将若干基本原则铭记于心，并在正确场合下正确使用它们。在很多项目中，安全问题被认为是事后考虑的事情，所以系统架构师和开发人员早期不会考虑它们。但如果在项目开始（架构和设计时期）不将安全问题牢记于心，如何能在合适的时候正确的使用 .NET Framework 提供的所有安全功能呢？

       因此，在开发最初就考虑安全性问题是非常重要的，这样才可能在创建架构和设计时，对安全问题作出正确的决策。

1. 理解潜在的威胁

       创建安全的架构和设计需要你对程序的运行环境有非常深入的了解。谁会访问你的程序？哪儿可能会成为攻击点？因此，安全首先基于你对周围环境因素的充分了解，比如用户、登录点和潜在的可能攻击点的威胁。

       这也是威胁模型在现代软件开发流程中日益重要的原因。威胁模型采用结构化的方法分析程序环境中的威胁，对这些威胁进行评级，然后基于这些威胁选取减缓它们的技术。这样，对安全技术（比如验证或 SSL 加密）的决策总是建立在现实依据（威胁自身）的基础上的。

       威胁模型之所以重要，还有另外一个原因。不是所有的潜在威胁都可以使用验证和授权机制等技术来减轻。换言之，一些潜在的威胁是无法用技术手段解决的。比如，在线银行可以使用 SSL 来保证银行网站的安全传输，但用户如何才能知道他们访问的是银行网站，而不是黑客伪装过的网站呢？目前唯一可行的途径是通过查看用来建立 SSL 通道的证书来确定网站。

       威胁模型是一个很大的主题，有一本书对于项目经理和架构师非常重要：Michael Howard 和 Steve Lipner 著的 Security Development Lifecyle。这本书重点讲述了如何让安全成为软件开发声明周期的一部分，从开始的计划阶段到架构、开发、测试和维护。它总结了微软的项目管理是如何让安全以平滑、实用的方式成为整个项目的一部分。

2. 安全编程原则

       仅有安全的架构和设计不会使你对程序安全高枕无忧，它只是其中重要因素之一。你还必须写出安全的代码。具体到 Web 程序，应当将如下原则牢记于心：

• 绝不相信用户的输入：要假定每一个用户都是恶意的，除非你能证明他不是。用户输入的信息总是要强制进行验证；只根据有效值去验证；你不可能想得出所有的无效值，它总会比你想象的更多。
• 绝对不要使用字符串连接符来创建 SQL 语句：应总是使用参数化的语句来确保程序不会被 SQL 注入。
• 绝对不要将没有经过验证和编码的用户输入直接显示在网页上：用户可能会输入一些代码片段（攻击脚本）。在输出页面数据之前，一定要使用 HttpUtility.HtmlEncode() 来转义特殊字符，或使用 Web 控件自动执行编码工作。
• 绝对不要将敏感数据、关键业务数据以及影响企业内部决策的数据以隐藏字段的形式存储在网页上：只要查看网页的源代码、修改它并将其保存到本地文件中就可以轻易的修改隐藏字段。攻击者只要将本地的网页提交到服务器就可以实现攻击。
• 绝对不要将敏感数据或者关键业务数据存储在视图状态：视图状态是页面上另一个隐藏区域，它也可以轻易的被解码查看。视图状态加密虽然能帮助保护在一段很短的时间里有用的信息，但如果攻击者拥有充分的时间、资源和动机，即使加密的信息也可以被破解。
• 使用基本验证或者 ASP.NET 的表单验证时启用 SSL：关于 SSL 后续系列会详细介绍。
• 保护 cookie：当使用表单验证时，一定要保护用于验证的 cookie，并尽可能的设置超时时间为更短。
• 使用 SSL：通常，Web 程序需要处理敏感数据就应该使用 SSL 来保障整个网站的安全，同时不要忘记使用 SSL 来保护本不是由应用程序直接管理的图片目录或存放其他文件的目录。

       以上只是基本的重要原则，具体到应用程序，你需要创建威胁模型来生成潜在威胁的完整列表。另外，如果你忘了上述任何一个指导原则，其他的安全特性就形同虚设了。系统的安全强度取决于它最薄弱的环节！

3. Gatekeeper

       一个增强应用程序安全性的好方法是部署很多的组件来加强安全性。Gatekeeper（安全守卫）是一个概念模式，它将流水线模型应用到系统安全架构中。Gatekeeper 假定一个安全的程序应该部署更多的安全机制，而不仅仅是必需的安全机制。

       ASP.NET 的程序架构也使用了这种机制。ASP.NET 包含有若干 Gatekeeper，每一个都被用来增强一些安全条件。在后续的文章中，你将会了解 ASP.NET Framework 包含的各种 Gatekeeper 以及它们各自的责任。

理解安全级别

       对于主流的 Web 应用程序来讲，实现安全的基本任务通常是相同的：

• 验证：验证会问这样的问题：这是谁？它确定谁在另一端使用你的程序。
• 授权：授权会问这样的问题：你可以执行什么样的操作？你可以访问什么资源？你的操作权限是什么？
• 机密性：当用户使用程序时，你必须保证没人可以查看这个用户正在处理的敏感数据。因此，你需要对客户端的浏览器和 Web 服务器之间的通道进行加密。你还可能必须加密存储在后台的数据，甚至数据库管理员或网站托管公司的员工都不能查看这些数据。
• 完整性：你必须保证数据在客户端和服务器端传输的过程中没有被非授权者修改过。数字签名提供了一个减轻这种威胁的途径。

       ASP.NET 包含了一个用来执行验证和授权的基本架构。.NET Framework 基类库包含一些位于 System.Security 命名空间中的类，用来加密数据并对数据签名。此外，客户端和服务器之间传送的数据，SSL 是保证数据机密性和完整性的标准化方式。

1. 验证

       验证是发现一个用户的身份并保证此身份真实性的过程。在 ASP.NET 应用程序中，有以下 4 个验证系统：

• Windows 验证
• 表单验证
• Passport 验证
• 自定义验证

       在每种验证系统中，用户都必须在登录时提供一些证明信息。系统根据验证类型的不同而采取不同的方式来跟踪用户身份。比如，Windows 操作系统使用一个 96 位的 SID（安全标识符）确定每一个登录用户；表单验证中，用户被赋予一个存储在 cookie 里面的验证票据，其中包含了各种加密过的数据。

       所有的验证都允许程序在处理每次请求时识别用户身份。它可以满足个性化和定制化的需要，身份信息在网页上展示用户特定的信息，或改变网站的外观。但验证本身并不足以限制用户被允许执行的任务。

2. 授权

       授权是决定分派给已验证用户的权力和限制的过程。授权是以这个用户所属的角色或者组为基础的，而不是这个用户是谁。很多情况下，基于角色的授权机制是非常可取的，实施起来非常容易。例如，角色可能被分为经理、管理员、游客、销售人员、客户等等。

       Web 应用程序在不同级别上进行不同类型的授权。比如在最高级别，代码可以检查用户的身份并决定某个特定的操作是否继续。在较低级别上，你可以配置 ASP.NET 禁止用户或角色访问特定的目录和网页。在更低层的级别上，当执行不同的任务（连接数据库、打开文件、写入事件日志等），Windows 操作系统会检查执行这些代码的用户的权限。

       大多数情况下，你不需要使用最底层级别，因为代码总是以一个固定帐号执行。在 IIS 7.x 中，是 Network Service 帐号。

3. 机密性和完整性

       机密性：数据在网络传输过程中或在数据库之类的存储设备中存储时不会被未经授权的用户查看。

       完整性：数据在网络传输过程中或在数据库之类的存储设备中存储时没有人能修改它。

       这两者以加密为基础。加密是将数据不规则化以使其他用户无法阅读的过程。在 ASP.NET 中，加密功能对验证、授权、身份模拟来讲是完全独立的。可以一起使用，也可以单独使用加密功能。

• 保护数据传输：SSL 是解决此问题的行业标准。SSL 也通过数字签名来保证数据的完整性。但 SSL 不是由 ASP.NET 实现的，而是 IIS 提供的一个功能。无论是否使用 SSL，你的页面程序（或 Web 服务）代码都是一样的。
• 保护永久信息：你应该在存储数据之前使用 .NET 提供的加密类对它们进行手工加密。

       另外，.NET 加密类可以用在任何类型的 .NET 程序中，并非只用于 ASP.NET 或 ASP.NET MVC 等网络应用程序中，这点不要混淆。

互相协作

       Web 应用程序中，验证、授权、身份模拟是如何互相协作的呢？

       当用户首次访问网站，他们是匿名的，你并不关心他们是谁，他们可以访问任何网页。但当用户请求一个匿名用户无法访问的页面时，会发生以下几个步骤：

1. 因为无法得知用户身份，所以会要求用户登录（自定义登录网页或者登录的弹出框等），这取决于你使用何种类型的验证方式。
2. 用户提供身份，你的程序来检验（使用表单验证） 或者 由 IIS 自动检验（使用 Windows 验证）。
3. 通过了验证，用户被赋予页面的访问权限。否则，会被提示再次登录或者导航至某个“拒绝访问”页面。

       如果是访问了一个只允许特定用户或特定角色才能访问的页面，那么在上述过程中，在身份验证通过后，还需进行角色的验证等。