IDC资讯中心
在本章中
构建安全的分布式web应用程序是一项极具挑战性的任务。用户应用程序的安全程度受应用程序中最薄弱环节的制约，而分布式应用程序会拥有许多环节。用户必须具备行之有效的知识，掌握多种产品和技术，令一个分布式应用程序的所有组成部分能够以某种安全方式进行联合工作。
本章描述了构建安全的分布式web应用程序的基础知识：authentication, authorization, and secure communications.身份验证、授权和安全通信。本章还介绍了一组关键的安全原则，用户在建立分布式 web 应用程序时应当重点注意。
目标
使用本章能够：
| • |
理解本指南的上下文中术语身份验证、授权和安全通信的意义。 |
| • |
理解高层asp.net web 应用程序的整体体系结构。这意味着要理解构成体系结构的技术以及每种技术所提供的身份验证、授权和安全通信选项。 |
| • |
理解构成本指南其余部分基础的关键安全原则。 |
适用于：
本章适用于下列产品和技术：
| • |
microsoft_ windows_ xp 或 windows 2000 server 及后续操作系统 |
| • |
.net 框架的1.0版本及后续版本 |
| • |
asp.net 1.0 |
如何使用本章
为从本章获得最大的收益：
| • |
用户必须熟悉微软的产品和技术，其中包括 windows、microsoft sql server™ 2000、internet information services、.net 框架及企业级服务 (com+) 。 |
| • |
用户必须拥有开发 asp.net web 应用程序的经历。 |
本页内容
 |
互连环境 |
|
基础知识 |
|
与技术的配合 |
|
设计原则 |
|
小结 |
互连环境
如果您已经知道如何建立安全应用程序，那么在您建立.net web 应用程序时能够应用所掌握的知识吗？在目前基于 web 的公布式应用程序环境中，web 服务将公司与公司连到一起，将公司与客户连到一起，而且应用程序会有不同程序的显露，比如显露给 intranet、extranet 及 internet 上的用户，对于这些，您能在这种应用环境中应用所掌握的知识吗？
请考虑一下这种互连环境的几点基本特性：
| • |
web 服务使用的标准包括简单对象访问协议（simple object access protocol，soap）、可扩展标记语言（extensible markup language，xml）和超文本传输协议（hypertext transport protocol，http）等标准，但是，它们基本使用纯文本传递潜在的机密信息。 |
| • |
internet b2c应用程序通过web传递机密数据。 |
| • |
extranet b2b应用程序模糊了信任界线，允许合作伙伴公司中的其他应用程序调用应用程序。 |
| • |
在维护工资表和人力资源（hr）应用程序的机密性方面，intranet 应用程序也存在风险。此类应用程序尤其容易因管理员不负责任和某些员工心怀不满而遭受到攻击。 |
基础知识
任何成功应用程序的安全性策略都是建立在可靠方法之上的，需要将身份验证、授权与安全通信联合起来才能够提供机密数据的保密与完整。在继续介绍之前，对这些核心概念进行定义是非常重要的。在“ 身份验证与授权”章中，我们将介绍如何将各种身份验证与授权机制结合起来，提供可靠的安全设计。
身份验证
身份验证明确识别应用程序的客户端，客户端可能包括最终用户、服务、进程或计算机。在安全用语中，首先要指出的就是经过身份验证的客户。
身份验证在一个分布式 web 应用程序的层间进行。最终用户最初由 web 应用程序进行身份验证，一般需要提供用户名和口令。随后，当中间层的应用程序服务器（如果用户的体系结构中有这一层的话）和数据库服务器在处理最终用户的请求时，它们要执行身份验证，从而确认并处理请求。
在许多应用程序中，下游服务器和组件不对最终用户进行身份验证。它们只对作为上游应用程序的实体进行身份验证，信任该应用程序进行正确的身份验证并在转发请求之前进行授权。
适用于 asp.net 应用程序开发的许多身份验证机制将在“ 适用于 asp .net 应用程序的安全模型”一章中进行进一步的讨论。
授权
授权过程管理经过身份验证了的客户所允许进行访问的资源与操作。资源包括文件、数据库、表、行等，还包括系统级资源，如注册表项和配置数据。
首先，对于可度量和易管理的资源，许多 web 应用程序通过方法、而不是直接对这些资源的操作进行授权访问。也即，对于系统级资源而言，使用平台级的安全，诸如 windows acl等，仍是必需的。许多最常见的应用程序级授权方案使用角色来对应用程序内部共享相同权限的用户组进行分类。
适用于 asp.net 应用程序开发者的各种授权选项与网关守卫将在“ 适用于 asp .net 应用程序的安全模式”一章中进行进一步的讨论。
安全通信
许多应用程序在应用程序层之间、从数据库服务器向浏览器、或者从浏览器向数据库服务器传递机密数据机密数据的示例包括有银行帐户的详细资料、信用卡号、工资数据，等等。此外，应用程序在网络间穿行时，必须保护登录凭据。
安全通信提供了下列两种特性：
| • |
隐私.隐私的概念是与数据保持私有和保密相联系的，不能被装备了网络监控软件的窃听者查看。隐私通常由加密机制提供。 |
| • |
完整性.安全通信通道还要保护数据在传输时不会被意外地或故意地（怀有恶意地）修改。完整性通常要使用信息鉴定码（message authentication code，mac）来提供。 |
同时在防火墙的内外使用安全通信是非常重要的，因为许多有害的信息显露和安全后门会出现在公司网络的内部。
安全通信及各种适用的方法将在“ 通信安全”一章中进行进一步地讨论。
与技术的配合
asp.net web 应用程序可以使用多种不同的技术和产品进行开发。在应用程序的多个层次上都需要使用各种身份验证、授权和安全通信的方法来确保具备深度安全策略上的防护。
图1总结了各种技术以及每种技术所提供的基本身份验证和授权方法。
图1. .net web 应用程序的安全性
设计原则
有若干重要原则适用于后面各章中提供的指导说明。您应当学会这些原则并在自己的应用程序设计中予以应用：
| • |
采用最少权限的原则.运行脚本或执行代码的进程应当尽可能用权限最少的帐户运行，从而在危及进程安全时限制可能造成的破坏。如果恶意用户设法将代码注入某个服务器进程，那么授予该进程的权限会在很大程度上决定该用户可执行的操作类型。应当将需要更多信任（和更高权限）的代码分别隔离在不同的进程内。 asp.net 小组有意识地决定运行拥有最少权限的 asp.net 帐户（使用 aspnet 帐户）这一修改在 .net 框架的最初版本中得以实现。但在 .net 框架的测试版中，asp.net 作为system运行，从本质上来说是一种较不安全的设置。 |
| • |
使用纵深防御。在应用程序的每一层和每个子系统中设置检查点。检查点是网关守卫，它们确保只有经过身份验证和授权的用户能够访问下一个下游层。 |
| • |
不要信任用户输入。应用程序应当彻底地验证所有用户输入，然后再根据用户输入执行操作。验证可能包括筛选特殊字符。针对用户意外地错误使用和某些人通过在系统中注入恶意命令蓄意进行攻击的情况，这种预防性措施对应用程序起到了保护作用。常见的例子包括 sql 注入攻击、脚本注入和缓冲区溢出。 |
| • |
使用默认安全设置。开发人员往往仅仅为了使应用程序运行而使用安全性较低的设置。如果应用程序所需的功能使您不得不减小默认安全设置或更改这些默认的安全设置，请在更改前测试更改所带来的后果并了解可能带来的隐患。 |
| • |
不要通过隐藏来保障安全。尝试使用让人迷惑的变量名来隐藏机密信息或将它们存储在不常用的文件位置，这些方法都不能提供安全保障。在“捉迷藏”游戏中，最好使用平台功能或使用已被证实可行的技术来保护数据。 |
| • |
在关口进行检查。您不必总是将用户的安全上下文传递到后端进行授权检查。通常，这种做法在分布式系统中并不是最佳选择。在关口检查客户端意思是在第一个身份验证点（例如，web 服务器上的 web 应用程序内）授予用户权限，并确定允许用户访问的资源和操作（可能由下游服务提供）。 如果在关口设计可靠的身份验证和授权策略，就不必将原调用方的安全上下文一路委派到应用程序数据层。 |
| • |
假定外部系统是不安全的系统。如果外部系统不归您所有，不要假定有人为您保证安全。 |
| • |
减小表面区域。避免公开不需要公开的信息。如果公开这些信息，就可能进一步引起漏洞。同时，处理错误的方式一定要适当。向最终用户返回错误消息时，不要公开任何不需要公开的信息。 |
| • |
以安全的方式显示错误消息。如果应用程序失败，一定要保护好机密数据。同时，不要在错误消息中提供过于详细的数据，也就是不要提供任何有助于攻击者发现应用程序漏洞的详细信息。详细的错误信息应写入 windows 事件日志。 |
| • |
不要忘记您的安全程序受最薄弱环节制约。考虑安全性时，应该将应用程序所有层的安全性都考虑在内。 |
| • |
禁用不使用的内容。您可以通过禁用应用程序不需要的模块和组件来去除一些潜在的攻击点。例如，如果应用程序不使用输出缓存，则应禁用 asp.net 输出缓存模块。这样，即使以后在该模块中发现安全漏洞，应用程序也不会受到威胁。 |
