对于在公司防火墙之外发布一个辉煌的新Web服务有点紧张?应该如此。本小节将讨论实施Web服务时用于保护你的网上资产的基本安全事项和Web服务专用技术。
Web服务安全措施
由于Web服务是相对新颖的技术,它的安全技术不断地进步。在编写本书的时候,必须实施经典的Web应用安全最佳实践,同时也要关注开发中的安全标准,如WS-Security。本小节我们将讨论这两种手段。
验证
如果你在HTTP上实现Web服务,对服务的访问可以用和Web应用相同的方式进行限制,可以使用第4章中讨论过的标准HTTP验证,如基本验证、摘要验证、Windows集成以及SSL客户端证书。自定义的验证机制也是可行的,例如,在SOAP首部中传递验证凭据或者主体元素。因为Web服务将业务逻辑发布到组织的外围,所有服务连接的验证都应该深入考虑。大部分Web服务的模型都集中于企业到企业的应用而不是企业到客户的,将访问权限制在一群至少是半可信的用户里应该更容易。尽管如此,第4章中讨论过的所有基本HTTP验证技术都面临着攻击,所以不要过分自信。
SSL
因为所依赖的XML通常是明文,所谓SOAP、WSDL和UDDI等Web服务技术特别容易在网络上传递时暴露在窃听和篡改之下。这不是一个新问题,已经使用第1章中讨论过的安全套接字层克服。我们强烈建议用SSL与Web服务结合,保护简单的窃听和篡改攻击。
XML Security
由于Web服务大多在XML上建立,开发出了许多提供基本安全架构的标准来支持服务的使用。下面是这些开发中的技术的简短概述——更多信息的链接可以在本章结尾处的“参考与延伸阅读”小节中找到。
·XML Signature: 描述使用XML的数字签名的一种规范,为XML文档或部分提供验证、消息完整性和不可否认性。
·安全断言标记语言 (Security Assertion Markup Language,SAML):共享验证和授权信息的格式。
·可扩展的访问控制标记语言 (Extensible Access Control Markup Language,XACML):信息访问策略的一种XML格式。
WS-Security
2002年4月11日,Microsoft公司、IBM公司和Versign公司宣布发行新的Web服务安全规范Web服务安全性语言(Web Services Security Language,又称WS-Security,这个规范的链接参见本章结尾处的“参考与延伸阅读”小节)。WS-Security包含和扩展了IBM和Microsoft之前提出的类似规范(也就是SOAP-Security、WS-Security和WS-License)中表达的思路。
实质上,WS-Security定义了一组SOAP扩展,可用于实现Web服务通信中的验证、完整性和机密性。更具体地说,WS-Security描述一种格式,用于SOAP消息中的数字签名、加密数据和安全令牌(包括二进制元素如X.509证书和Kerberos票据)。WS-Security很大程度上利用了之前提到的XML安全规范——XML Signature和XML Encryption——意图是成为许多其他规范的构件,这些处理安全相关方面的构件包含WS-Policy、WS-Trust、WS-Privacy、WS-SecureConversation、WS-Federation及WS-Authorization。
描述WS-Security的最佳方式是通过一个示例。下面的SOAP消息包含新的WS-Security首部和加密载荷(我们在左列加入行号,便于描述单个消息功能):
(001) <?xml version="1.0" encoding="utf-8"?> (002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> (003) <S:Header> (004) <m:path xmlns:m="http://schemas.xmlsoap.org/rp/"> (005) <m:action>http://stocktrader.edu/getQuote</m:action> (006) <m:to>http://stocktrader.edu/stocks</m:to> (007) <m:from>mailto:bob@stocktrader.edu</m:from> (008) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id> (009) </m:path> (010) <wsse:Security> (011) [additional headers here for authentication, etc. as required] (012) <xenc:EncryptedKey> (013) <xenc:EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> (014) <ds:KeyInfo> (015) <ds:KeyName>CN=Alice, C=US</ds:KeyName> (016) </ds:KeyInfo> (017) <xenc:CipherData> (018) <xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0... (019) </xenc:CipherValue> (020) </xenc:CipherData> (021) <xenc:ReferenceList> (022) <xenc:DataReference URI="#enc1"/> (023) </xenc:ReferenceList> (024) </xenc:EncryptedKey> (025) [additional headers here for signature, etc. as required] (026) </wsse:Security> (027) </S:Header> (028) <S:Body> (029) <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" Id="enc1"> (030) <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc"/> (031) <xenc:CipherData> (032) <xenc:CipherValue>F2m4V0Gr8er94kl3o2hj7... (033) </xenc:CipherValue> (034) </xenc:CipherData> (035) </xenc:EncryptedData> (036) </S:Body> (037) </S:Envelope>
我们来研究这个SOAP消息中的一些元素,看看WS-Security如何提供安全性。在第3行,我们看到SOAP首部的开始,接着在第10行有新的WS-Security首部wsse:Security,这是SOAP首部中的WS-Security信息定界符。我们从第11行中注意到,一个SOAP消息中可能有多个WS-Security首部,描述验证令牌、加密密钥等。在我们的特殊示例中,已经展示了描述用于加密一部分SOAP消息载荷(第12行)的加密密钥的xenc:EncryptedKey首部。注意,这个加密密钥本身用消息接收者(第15行中的Alice)的公钥进行RSA不对称加密,加密载荷元素在第22行上以enc1引用。进一步,在SOAP消息主体的第29行,可以看到用这个密钥以3DES算法加密的数据(注意Id="enc1")。归纳起来,
·首部行18:3DES对称加密密钥(用接收者公钥加密)。
·主体行32:3DES加密数据载荷。
Alice可以接收这个消息,用它的私钥解密这个3DES密钥,然后使用3DES密钥解密数据。忽略验证和密钥分发问题,我们已经实现了这个SOAP消息载荷的强机密性。
尽管WS-Security提供了传输不可知的、细粒度的和特性丰富的端到端安全机制(与此相反,HTTP上的SSL/TLS工作于点对点的场景下),但由于加密处理(加密和签名)以及SOAP消息尺寸的增加,仍然增加了WS-Security的复杂性和显著的开销。为了确定WS-Security是否比其他选项如HTTPS更加适合于你,必须详细分析你的系统和架构的具体特性。
XML防火墙
在Web服务的发展同时,特殊的安全系统如XML防火墙也已经迅速发展起来。和传统的第三层防火墙不同,XML防火墙聚焦于保护Web服务固有的应用层XML消息,使其免遭本章概述的常见攻击(消息和解析器类攻击)。提供纵深防御总是受欢迎的,特别是对于Web服务提供的敏感的编程接口。但是,XML防火墙还没有成为加强Web服务安全的公认方法。这种情况源于很多因素,包括典型的Web服务内建的验证和SSL保护的可用性,在许多场合下全能的安全网关定制时效率下降的程度,以及传统防火墙技术对应用领域的侵蚀,更高的应用感知能力已经使现有的硬件和软件也能提供相同的保护。