Web services是一种技术，它承诺通过应用与驱动Web革命相同的基于XML的技术，使系统集成发生革命性的变化。然而，尽管许下了这个庄严的誓言，Web services技术还是经常被人误解。主要的原因在于它的名称本身，“Web services”暗示着是“在World Wide Web上提供的服务”。然而事实上，第一波Web services正隐退到防火墙之后，用于把后台系统链接在一起。大多数企业没有意向在不久的将来跨防火墙发送XML。那么，这个因素是否意味着安全不是问题呢？不幸的是，答案是否定的。让我们看一看Web services带来的安全性挑战，现今如何使用安全架构来解决它们，以及当XML穿过防火墙时，如何针对未来的需要扩展前述安全架构。
首先，让我们回顾一下什么是Web services，以及为什么它们会带来安全性挑战？Web services是允许应用程序使用XML相互通信的一组技术。简单对象访问协议（Simple Object Access Protocol，SOAP）规范描述了通过给XML数据应用封套（envelope），从而在应用程序之间发送这些XML消息的方法。SOAP原本计划用作在对象之间发送函数调用的一种方式，因此才使用这个首字母缩写词。然而，从SOAP 1.2开始，“SOAP”不再代表它原来的意义，因为它的用途已经扩展，远不止用于在软件对象之间进行通信这么简单。SOAP正逐渐确立自己的合适定位，即作为应用程序之间的消息传送系统，也就是应用程序的e-mail。
SOAP消息一般是基于标准的Web协议通过HTTP发送的。在过去的5年中，安全套接字层（Secure Sockets Layer，SSL）已经广泛用作用于HTTP的安全技术。通过使用X.509数字证书进行加密和身份验证，SSL可以为HTTP流量提供机密性。另外，有许多授权工具控制对Web站点的访问，并跨Web站点管理单点登录会话。这些年来，Web services和Web应用程序已经暴露出许多安全问题，这些问题均被完整地记录在案，而且也出现了大量的最佳实践信息，用于描述如何解决和补救这些问题。考虑所有这些信息，对于保护Web services来说，现有的安全解决方案，比如SSL、Web访问控制工具和频繁地打补丁是否已经足够？答案是否定的。让我们看一看上述方案都不如SOAP的三个安全性原因。
三个安全问题
为什么使用SSL尚不足够? 尽管SOAP经常基于HTTP发送消息（术语称为“绑定到HTTP”），但是它不一定非得如此。SOAP是独立于底层通信层的。SOAP消息也可以基于e-mail（即简单邮件传输协议）或FTP（就像早期的做法那样）进行发送。事实上，因为HTTP是无状态的，并非完全可靠，许多企业都没有意向使用它来传输SOAP消息。
在一个事务环境中，对一条简单的SOAP消息可以使用多种不同的传输方式——例如，对传输的第一段使用HTTP，然后对下一段使用SMTP，等等。正如我们看到的那样，SSL为单个点到点HTTP会话提供机密性和身份验证，但它不提供用于保证会话发生的审核追踪（audit trail）。
针对这个问题的解决方案是将安全性应用给SOAP消息本身，而不是依赖于发送SOAP消息时使用的传输协议。这种解决方案确保即使是基于不安全的传输协议发送SOAP消息，或者如果它通过几段不被信任的服务器，也仍然是安全的。记住，我们把SOAP链接到应用程序之间的e-mail，以e-mail类推在这里也成立。如果在Internet上发送e-mail消息，仅仅对e-mail服务器之间的链接进行加密是不够的。必须对e-mail消息本身进行加密。SOAP消息也是如此。万维网联盟（World Wide Web Consortium，W3C)和结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）已经为此目的制订出一些新的规范。XML Signature和XML Encryption描述了如何强制实现XML文档的完整性和机密性，而WS-Security则把这些XML安全技术应用到SOAP消息。
谁要访问这个Web services? SOAP请求是由应用程序，而不是人生成的。然而，安全决策通常依赖于人的身份。设想一种情况，保险中介对在索赔门户中使用的密码进行身份验证，然后使用请求索赔信息填写一个Web表单（参见图1）。SOAP消息代表代理从索赔门户被发送到许多保险公司。保险公司使用传输层安全对SOAP请求的发送者（即索赔门户）进行身份验证。然而，如果保险公司要求具有能够查看谁是代理或者关于代理的属性信息的能力，应该怎么办呢？安全环境必须从使用密码身份验证的最终用户扩展到使用SOAP消息运行的Web services。这里的安全难题是将有关最终用户的安全信息插入到SOAP消息中。该信息涉及到代理的身份验证状态，已授权他们执行的操作，以及可用于进行访问控制决策的其他代理属性。
传输层安全对SOAP请求的发送者进行身份验证。正如我们这个代理保险公司的例子中指出的那样，安全环境必须从使用密码身份验证的最终用户扩展到使用SOAP消息运行的Web services。安全难题是将有关最终用户的安全信息插入到SOAP消息中。
OASIS发布的安全断言标记语言（Security Assertion Markup Language ，SAML）规范描述了如何把这类信息作为关于最终用户的断言格式化到XML中，而且OASIS中的WS-Security小组正在定义如何把这些断言放入SOAP消息。企业已经拥有目录和用户配置文件，它们希望通过重用这些来保护对Web services的访问。
将坏人拒之门外。可以将XML Signature、XML Encryption、WS-Security和SAML这样的技术视作Web services安全的正面，这些新的规范和协议将当前的安全技术扩展到了XML世界。相反，保护不受新类型的黑客攻击就是负面。如果要求用户按照其角色行事，Web services和Web services安全工具就是无用的。如果一个使用SAML和WS-Security的完善身份验证系统运行在一个Web services上，而CodeRed攻击可以禁用该Web services，那么这个身份验证系统就是无用的。
Web services面临的大多数新威胁实际上过去就已存在，比如由编程错误和配置失误引起的缓存溢出，但是攻击SOAP的手段却是新的。传统上，防火墙可以保护开放源代码促进会（Open Source Initiative，OSI）堆栈的下层不受攻击。防火墙的功能已经逐渐向上移动到OSI堆栈的应用层。对于防火墙来说，针对SOAP的智能能力意味着基于消息的内容和格式过滤SOAP消息，具体方法是依靠XML Schema定义和XPath语句来验证它们。
防火墙有哪些功能?
许多防火墙的配置只运行Web（HTTP、SSL）和e-mail（POP、SMTP）流量通过。其他TCP/IP端口和其他协议均被封锁。有效地伪装成普通的Web流量，然后通过Web端口（HTTP使用80端口，SSL使用443端口）连接到其他应用程序已经成为标准的实践。这类伪装通常出于恶意的目的，而不是实用的目的，因为所有其他端口均被封锁。
我们已经明白，SOAP经常绑定到HTTP。当防火墙检查一个通过HTTP接收到的SOAP请求时，它可能断定这个请求是有效的HTTP流量，并让其通过。当面对SOAP时，防火墙往往要么不起作用，要么全部拦截，而这样做不好。SOAP级别的防火墙应该能够：1)识别进入的SOAP请求是不是以计划给请求者使用的Web services为目标，2)识别进入的SOAP消息的内容对目标Web services是否有效。该第二项功能类似于网络层的功能，即网络层检查IP包的内容，以确保它们适合于要访问的网络服务。然而，在应用层，这个过程需要精确地了解Web services期望的XML数据的格式和内容。XML Schema 和Web services描述语言（Web servicesDescription Language ，WSDL）可以提供这类精确的信息。
Web services在WSDL文件中表示它们接口的详细信息，该文件有效地假定，“此处给出我期望从你处收到的请求的描述”，吸引黑客发送给它不正确的数据，看看会发生什么事情。WSDL文件可能包含如下行：
<xsd:element name= "tickerSymbol" type="string"/>
这一行表明Web services期望的参数之一是一个字符串，叫做tickerSymbol。对此Web services进行的可能攻击包括，发送给它许多而不是一个字符串，或者发送给它一个非常大的字符串，目的是使该Web services过载。因此，在被定向到Web services的入站数据进行完整性检查（sanity check）是很重要的。这类检查的形式可能是检查XML Schema的SOAP参数。
选择架构
对于Web services安全有三种主要的架构选择。XML Gateway、Interceptor和自定义编码的XML Gateway——有时候称为XML防火墙或XML代理——是用于过滤Web的XML流量并在未授权流量到达受保护Web services之前阻塞它的软件包或应用程序（参见图2）。XML Gateway实施访问控制规则，具体方法是处理包含在进入的SOAP消息中的安全性标记，以及确保XML格式和内容对于目标而言是正确的。它可以使用SAML建立最终用户的身份验证状态，或者请求用于做出访问控制决策的属性信息。有一点很重要，即XML Gateway包含用于现有安全技术的安全性适配器，这些技术包括LDAP 目录、传统的防火墙和PKI。另外，把规则和用户配置文件重新嵌入到XML Gateway 中所带来的开销是不被允许的。XML Gateway 应该尽可能地重用已经预先配置用户、组和角色的安全性基础架构。
XML Gateway——或者XML防火墙或XML代理——是用于过滤Web services的XML流量，并在未授权的流量到达受保护的Web services之前阻塞它的软件包或工具。
单个XML Gateway可以保护许多Web services平台。XML Gateway不必与目标Web services共享一个操作系统，因为它们位于单独的主机之上。这种独立性意味着基于Linux的XML Gateway工具可以保护基于.Net和Java 2 Platform，Enterprise Edition（J2EE）的混合Web services。XML Gateway经常执行转换功能和安全功能。在XML世界中，这项功能等同于实现XSLT。
可以选择的另一种架构是在Web services平台上部署Interceptor。这些轻量级的Interceptor使用特定于平台的钩子，比如ISAPI Filters、JAX-RPC处理器或Apache Axis处理器。接着，Interceptor（有时称为“代理”）与集中式的XML安全服务器进行通信，该安全服务器负责处理安全规则（参见图3）。与XML Gateway的选择相比，这个架构将安全性实施放在更靠近Web services应用程序的地方。就像在XML Gateway场景中一样，它集中了安全性处理，这意味着Web services应用程序没有深陷在处理器密集型的功能（如加密）中。此外，就像XML Gateway架构一样，Interceptor架构为SOAP流量提供一个管理和报告的集中点。Interceptor架构与Gateway架构安全的区别在于，它的安全是在Web services端点自身上实施的，而不是要求XML流量从基础架构架设备通过以获得保护。
Interceptor或代理与负责处理安全规则的集中式XML安全服务器进行通信。与XML Gateway选择进行比较时，Interceptor架构将安全性实施放在了离Web services应用程序更近的地方。
第三个选择是在Web services自身中编写安全代码。.Net通用语言运行库（Common Language Runtime，CLR）包括XML Signature、XML Encryption和WS-Security的实现。程序员编写以.Net为宿主的Web services时可以使用这项功能。类似地，J2EE环境也包含开发人员可用的安全功能。用于自定义编码的参数是熟悉的“构建还是购买”的权衡。尽管Gateway和Interceptor模型为集中式管理和报告提供针对多个Web services进行全局修改的能力，但是如果编写特定于平台的解决方案，则必须定制这项功能。当然，编写您自己的解决方案可以免去软件许可证方面的费用，而且可能对拥有大批IT员工的企业来说更有意义。
无论选择何种解决方案，有一点很重要，即它并不限于第一代的、企业内部的Web services，在合适的时候，还可以将其应用于B2B Web services。在企业内部中部署可能对于学习Web services十分有用，但是如果要将一个不同的安全解决方案用于B2B Web services，那么前面的学习都将白费。Web services面临着新的安全问题，但是新的行业标准和新的XML安全产品将会解决这些问题。涉及XML安全性时，要选择架构，尽可能早地做出这些抉择是很重要的。
原文出处
http://www.fawcette.com/javapro/2003_08/magazine/features/moneill/
| 作者简介 | |
| Mark O'Neill是Vordel公司的CTO，Vordel公司是一家Web services安全公司。Mark是Web servicesSecurity（Osborne/McGraw-Hill，2003年1月。IBSN：0-0722-2471-1）一书的作者，经常做XML和Web services安全方面的演讲。他经常出外旅游，但同时也尽量抽出时间来陪他在波士顿的妻子Kristen以及他们新出生的孩子Ben。 | |
浙公网安备 33010602011771号