构建安全的 Web ServicesWord格式.docx
《构建安全的 Web ServicesWord格式.docx》由会员分享，可在线阅读，更多相关《构建安全的 Web ServicesWord格式.docx（37页珍藏版）》请在冰点文库上搜索。
该模块适合帮助管理员配置ASP.NETWeb应用程序或WebServices，使不太安全的应用程序变得安全。
参阅模块17确保应用程序服务器的安全。
参阅模块17，以便熟悉远程应用程序服务器的注意事项。
使用本指南中的“检查表”部分的检查表：
保护Web服务的安全。
该检查表总结了构建和配置安全的WebServices所需的安全措施。
使用本模块可以了解消息级别的威胁以及如何防御这些威胁。
并将应用程序类别作为一种解决常见问题的方法。
本节将使用这些类别给出相关的信息。
概述
越来越多的公司使用WebServices通过Internet和企业Extranet向客户和商业伙伴提供产品和服务。
这些服务提供商所需的安全要求非常高。
在某些情况下（主要是在Intranet或Extranet情况下，在这两种情况下，您对两个终结点都有一定程度的控制权），可以使用操作系统和Internet信息服务（IIS）所提供的基于平台的安全服务来提供点对点的安全解决方案。
然而，基于消息的WebServices体系结构和日益增加的跨信任边界的异构环境带来了新的挑战。
这些情况需要在消息级别上解决安全问题，以支持跨平台的互操作性和通过多个中间节点进行路由。
WebServices安全（WS-Security）是用来解决这些问题的最新安全标准。
Microsoft已经发布了WebServicesEnhancements1.0forMicrosoft.NET（WSE），以支持WS-Security和一组相关的最新标准。
WSE允许实施消息级别的安全解决方案，包括身份验证、加密和数字签名。
注意：
WSE支持的规范和标准是不断变化的，因此当前的WSE并不保证与该产品将来的版本兼容。
在写本文时，互操作性测试正在进行，使用的是由包括IBM和VeriSign在内的供应商所提供的非Microsoft工具包。
威胁与对策
要构建安全的WebServices，需要了解相关的威胁。
WebServices面对的主要威胁是：
未授权的访问
参数操纵
网络窃听
配置数据的泄漏
消息重播
图12.1显示了WebServices面对的主要威胁和攻击。
图12.1
主要的WebServices威胁
提供敏感或限制性信息的WebServices应对其调用者进行身份验证和授权。
攻击者可以利用弱的身份验证和授权机制，对敏感信息和操作进行未授权的访问。
漏洞
可导致通过WebServices进行未授权的访问的漏洞包括：
未使用身份验证
密码在SOAP头信息中以明文形式传递
在未加密的通信通道中使用基本身份验证
对策
可以使用下列对策防止未授权的访问：
在SOAP头信息中使用密码摘要进行身份验证。
在SOAP头信息中使用Kerberos票证进行身份验证。
在SOAP头信息中使用X.509证书进行身份验证。
使用Windows身份验证。
使用基于角色的授权来限制对WebServices的访问。
通过使用URL授权来控制对WebServices文件（.asmx）的访问，或在Web方法级别通过使用主要权限需求，实现此目的。
参数操纵是指对WebServices客户与WebServices之间发送的数据进行XX的修改。
例如，攻击者可以截获WebServices消息（例如，在通过中间节点到达目标的路由中），然后在将其发送到目标终结点前对其进行修改。
可能用于参数操纵的漏洞包括：
没有为防止篡改而对消息进行数字签名
没有加密消息以提供隐私保护和防止篡改
可以使用下列对策来防止参数操纵：
对消息进行数字签名。
数字签名用于收件人这一方，用来验证消息在传输过程中未被篡改。
加密消息有效负载，以便提供隐私保护并防止篡改。
通过网络窃听，当WebServices消息在网络中传输时，攻击者可以查看这些消息。
例如，攻击者可以使用网络监视软件检索SOAP消息中包含的敏感数据。
其中有可能包括敏感的应用程序级别的数据或凭据信息。
可以导致成功的网络窃听的漏洞包括：
凭据在SOAP头信息中以明文形式传递
没有使用消息级别的加密
没有使用传输级别的加密
可以使用下列对策来保护敏感的SOAP消息在网络中传递：
使用传输级别的加密，如SSL或IPSec。
只有在两个终结点都可以控制的情况下，才能使用此对策。
加密消息负载以提供隐私保护。
当消息通过中间节点路由到最终目标时，可以使用此方法。
WebServices配置数据的泄漏的方法主要有两种。
第一种，WebServices可能支持动态生成WebServices描述语言（WSDL），或者可能在Web服务器上的可下载文件中提供WSDL信息。
取决于具体情况，可能不需要此方法。
WSDL描述WebServices的特征，例如，它的方法签名和支持的协议。
第二种，如果异常处理不充分，WebServices可能会泄漏对攻击者有用的敏感的内部实施详细信息。
可以导致配置数据的泄漏的漏洞包括：
可以不受限制地从Web服务器下载WSDL文件
受限制的WebServices支持动态生成WSDL，并允许XX的客户获得WebServices特性。
弱的异常处理
可以使用下列对策防止意外配置数据的泄漏：
使用NTFS权限限制对WSDL文件的访问权。
从Web服务器上删除WSDL文件。
禁用文档协议以防动态生成WSDL。
捕获异常，并抛出SoapException或SoapHeaderException，仅向客户端返回最少信息或无害信息。
WebServices消息可能会在传递过程中经过多个中间服务器。
通过消息重播攻击，攻击者可以捕获并复制消息，并模拟客户端将其重播到WebServices。
消息可能被修改，也可能保持不变。
可以导致消息重播的漏洞包括：
消息未经加密
消息未经数字签名以防止篡改
由于没有使用唯一的消息ID，因此无法检测重复的消息
攻击
最常见的消息重播攻击包括：
简单重播攻击。
攻击者捕获并复制消息，然后重播此消息，并冒充客户端。
这种重播攻击无需恶意用户了解消息的内容。
中间人攻击。
攻击者捕获消息，然后更改部分内容（如送货地址），然后将其重播到WebServices。
可以使用下列对策解除消息重播的威胁：
使用加密的通信通道，如SSL。
加密消息负载，以提供隐私保护并防止篡改。
尽管这种方法不能防止简单的重播攻击，但它确实可以防止中间人攻击，避免了消息内容被修改后再重播。
每个请求都应使用唯一的消息ID或Nonce来检测副本，并对消息进行数字签名以防篡改。
Nonce是用于请求的、经过加密的唯一值。
服务器响应客户端时，将发送唯一的ID并对该消息进行签名（包括此ID）。
当客户端产生其他请求时，将在消息中包含此ID。
服务器确保客户端发出的新请求中的ID与发送给客户端的前一个消息的ID是相同的。
如果两者不同，则服务器将拒绝此请求，并假定正遭受重播攻击。
攻击者无法欺骗此消息ID，因为该消息是经过签名的。
请注意，这种方法仅保护服务器免遭由客户端使用消息请求发起的重播攻击，但不为客户端提供针对重播响应的保护。
设计注意事项
准备开发WebServices之前，需要在设计阶段考虑许多问题。
主要的安全注意事项包括：
身份验证要求
隐私和完整性要求
资源访问标识
代码访问安全
如果WebServices提供了敏感或限制性信息，就需要对调用者进行身份验证以便授权。
在Windows环境中，可以使用Windows身份验证。
然而，如果无法同时控制两个终结点，则可以使用WSE。
WSE提供了遵守最新WS-Security标准的身份验证解决方案。
WSE提供了一个标准框架，可以使用SOAP头信息以用户名和密码、Kerberos票证、X.509证书或自定义令牌来传递身份验证的详细信息。
有关详细信息，请参阅本模块后面的身份验证部分。
如果在WebServices的请求或响应消息中传递敏感的应用程序数据，应考虑如何确保这些数据在传输过程中处于保密状态，并且没有被更改。
WSE通过数字签名提供了完整性检查，并且还支持XML加密，对整个消息负载的敏感元素进行加密。
此方法的优点在于它是基于最新的WS-Security标准，并为通过多个中间节点传递的消息提供了一种解决方案。
另外一种方法是使用通过SSL或IPSec通道的传输级别加密。
该方案仅适用于可以同时控制两个终结点的情况。
默认情况下，ASP.NETWebServices不进行模拟，并使用权限最小的ASPNET进程帐户访问本地和远程资源。
可以使用此ASPNET进程帐户访问远程网络资源，例如，可以通过在数据库服务器上创建本地帐户的镜像，来访问SQLServer（需要Windows身份验证）。
在WindowsServer2003上，默认情况下使用NetworkService帐户运行WebServices。
有关使用ASP.NET进程帐户远程访问数据库的详细信息，请参阅模块19确保ASP.NET应用程序和Web服务的安全中的“数据访问”部分。
如果使用模拟，Web应用程序出现的各种问题和注意事项同样也出现于WebServices。
有关详细信息，请参阅模块10构建安全的ASP.NET网页和控件和模块19确保ASP.NET应用程序和Web服务的安全中的“模拟”部分。
以目标部署环境中的安全策略定义的信任级别为例。
WebServices的信任级别，是由该服务的<
trust>
元素配置定义的，可以影响该服务访问的资源类型和其他可执行的特权操作。
同样，如果从ASP.NETWeb应用程序调用WebServices，则该Web应用程序的信任级别就决定了可以调用的WebServices的范围。
例如，信任级别配置为中等信任的Web应用程序，在默认情况下只能调用本地计算机上的WebServices。
有关从中等信任或其他部分信任的Web应用程序调用WebServices的详细信息，请参阅模块9ASP.NET代码访问安全性。
输入验证
如同所有接受数据输入的应用程序一样，WebServices也必须验证所接收的数据，以便实施业务规则和防止可能的安全问题。
标记为WebMethod属性的Web方法是WebServices的入口点。
Web方法可以接受强类型的输入参数或通常以字符串数据传递的松散类型的参数。
这通常取决于设计WebServices的客户的范围和类型。
强类型参数
如果使用由.NETFramework类型系统描述的强类型参数（例如integer、double、date）或其他自定义的对象类型（如Address或Employee），则自动生成的XMLSchemaDefinition（XSD）架构就会包含该数据的类型描述。
客户可以使用该类型描述，在发送到Web方法的SOAP请求中，构造适当格式的XML。
然后ASP.NET使用System.Xml.Serialization.XmlSerializer类将传入的SOAP消息反序列化为公共语言运行库（CLR）对象。
以下示例显示了一个Web方法，该方法可以接受包含内置数据类型的强类型输入。
[WebMethod]
publicvoidCreateEmployee（stringname,intage,decimalsalary）{...}
在上一个示例中，.NETFramework类型系统自动进行类型检查。
要验证name字段提供的字符的范围，可以使用正则表达式。
例如，下列代码显示了如何使用System.Text.RegularExpressions.Regex类来限制输入字符的可能范围，并验证参数的长度。
if（!
Regex.IsMatch（name,@"
^[a-zA-Z'
.`-′\s]{1,40}$"
））
{
//无效的名称
}
有关正则表达式的详细信息，请参阅模块10构建安全的ASP.NET网页和控件中的“输入验证”部分。
下列示例显示了一个接受自定义的Employee数据类型的Web方法。
usingEmployees;
//自定义命名空间
publicvoidCreateEmployee（Employeeemp）{...}
客户需要了解XSD架构以便能够调用WebServices。
如果该客户是一个.NETFramework客户端应用程序，则可以简单地传递一个Employee对象，如下所示：
Employeeemp=newEmployee（）;
//填充Employee字段
//向WebServices发送Employee
wsProxy.CreateEmployee（emp）;
对于不是基于.NETFramework的客户应用程序，必须根据负责此WebServices的组织所提供的架构定义，手动构造XML输入。
这种强类型方法的优点是，.NETFramework可以对输入数据进行解析，并根据类型定义验证这些数据。
然而，您可能还需要在此Web方法内部对输入数据进行限制。
例如，尽管类型系统确认Employee对象有效，然而可能还需要对Employee的各个字段进一步验证。
您可能需要验证雇员的年龄是否大于18岁。
还可能需要使用正则表达式，来限制name字段使用的字符的范围等等。
有关限制输入的详细信息，请参阅模块10构建安全的ASP.NET网页和控件中的“输入验证”部分。
松散类型的参数
如果使用字符串参数或字节数组传递任意数据，将会失去.NETFramework类型系统的许多优点。
您必须手动解析输入数据，以便对其进行验证，因为自动生成的WSDL仅将这些参数简单描述为xsd:
string类型的字符串输入。
您需要以编程方式检查类型、长度、格式和范围，如下例所示。
publicvoidSomeEmployeeFunction（stringdateofBirth,stringSSN）
...
//示例1：
对日期进行类型检查
try
{
DateTimedt=DateTime.Parse（dateofBirth）.Date;
}
//如果类型转换失败就会抛出FormatException异常
catch（FormatExceptionex）
//无效的日期
//示例2：
检查社会安全保险号的长度、格式和范围
if（!
Regex.IsMatch（empSSN,@"
^\d{3}-\d{2}-\d{4}$"
RegexOptions.None））
//无效的社会安全保险号
XML数据
在经典的商业对商业方案中，客户经常传递表示业务文档（如购货订单或销售发票）的XML数据。
在对这些输入数据进行处理或将其传递到下游组件之前，必须通过Web方法以编程方式验证这些输入数据的有效性。
客户端和服务器必须建立描述XML的架构，并达成一致。
下列代码片段显示了Web方法如何使用System.Xml.XmlValidatingReader类来验证输入数据。
本例中的输入数据描述了一个简单的图书订单。
请注意，这些XML数据是通过简单的字符串参数传递的。
usingSystem.Xml;
usingSystem.Xml.Schema;
publicvoidOrderBooks（stringxmlBookData）
//创建并加载一个验证的reader
XmlValidatingReaderreader=newXmlValidatingReader（xmlBookData,
XmlNodeType.Element,
null）;
//将XSD架构附加在此reader上
reader.Schemas.Add（"
urn:
bookstore-schema"
@"
http:
//localhost/WSBooks/bookschema.xsd"
）;
//设置XSD架构的验证类型。
//也支持XDR架构和DTD
reader.ValidationType=ValidationType.Schema;
//创建并注册一个事件处理器，来处理验证错误
reader.ValidationEventHandler+=newValidationEventHandler（
ValidationErrors）;
//处理输入数据
while（reader.Read（））
...
//验证成功完成
catch
//验证错误事件处理器
privatestaticvoidValidationErrors（objectsender,ValidationEventArgsargs）
//从args.Message获得的错误详细信息
下列代码片段显示了客户如何调用以上Web方法：
stringxmlBookData="
<
bookxmlns='
bookstore-schema'
xmlns:
xsi='
//www.w3.org/2001/XMLSchema-instance'
>
"
+
title>
BuildingSecureASP.NETApplications<
/title>
isbn>
0735618909<
/isbn>
orderQuantity>
1<
/orderQuantity>
/book>
;
BookStore.BookServicebookService=newBookStore.BookService（）;
bookService.OrderBooks（xmlBookData））;
以上示例使用了下列简单的XSD架构来验证输入数据。
xsd:
schemaxmlns:
xsd="
//www.w3.org/2001/XMLSchema"
xmlns="
elementFormDefault="
qualified"
targetNamespace="
elementname="
book"
type="
bookData"
/>
complexTypename="
sequence>
title"
string"
/>
isbn"
integer"
orderQuantity"
/xsd:
complexType>
schema>
下表显示了其他复杂的元素定义，它们可以用于XSD架构以便进一步限制各个XML元素。
表12.1：
XSD架构元素示例
说明
示例
使用正则表达式限制XML元素
zip"
simpleType>
x
升级会员 