可扩展标识语言（XML）、Web服务和面向服务架构（SOA）在软件开发领域是最流行的东西。这些流行词在拥有成百上千个独立系统的大型企业中被炒得特别火热。如果这些没有联系的系统能用开放的标准来组织起来，一起工作，那么就可以减少大量的时间，资金和挫折。不论我们是否处在一个软件的新纪元，这个目标本身就足以让安全工程师战战兢兢。将系统A和系统B粘贴在一起可能容易，但这它们的结合是安全的么？

　　今天，关于Web 服务的大多数讨论聚焦在标准上：从WS-Security和SAML到底层的SOAP甚至XML。当标准成为重要角色，衡量Web服务的安全时就需要回过头看看标准，考虑系统可能失败的各种方式。攻击者会专注于系统的弱点，与此同时应该推出安全的系统评估。你要考虑到以下方面：

　　复杂的协议也许看起来有些臃肿或冗余。忽略或改变一些步骤对于正常操作可能不会引起问题，但它可能危害保证协议的安全。

　　支持Web服务应用平台要有难以置信的弹性。在实践中，这意味着它们有难以置信的复杂配置。这些配置文件的错误成为服务中的漏洞。

　　服务经常构建在遗留软件之上，而这些遗留软件最初并没有被设计成服务。在为攻击者们提供新的机会之前，容易受到攻击的代码从来没有向网络开放。

　　除了像这样的问题是SOA安全的任何综合方式的一部分。我们将看一下每个例子然后讨论业务软件保证技术，你应该利用这些技术来防止这些问题的发生。

　　多数很明白事理的人不至于建立他们自己的加密方法，但愿意尝试自制认证协议的程序员的数目仍然令人惊奇。上个月Google发现使用自制认证协议是个很糟糕的主意。他们在Google应用上使用的单点登录协议源自于SAML，但它忽视了在两个协议消息中一些表面上看起来不需要的信息。这样的结果是严重的安全瑕疵，它允许一个不诚实服务提供者扮演另一个服务提供者的用户。 这个故事的寓意是如果你采用了某一个标准，不要停留在“够用”的程度上。不明显的漏洞悄悄混进虽符合标准却出现问题的地方。

　　像WebSphere，WebLogic或.NET WSE这些Web服务容器的多样化令人惊奇，当它支持Web服务的时候，起初乍一看是个福音，但对不得不配置这些系统的人员变成了恶梦。人们从示例工程或连枷中将配置缝合起来，直到他们的服务开始工作。结果是服务配置并不是作者所期望的。下面的这个例子展示了Apache Axis2 Rampart的客户端配置了不需要加密的入栈消息（既然<items>标签没有包含加密的指令）。

　　当这个配置被深藏于庞大的配置文件中时，就很难捕捉错误。结果是Web服务没有给它的创建人提供想要的安全保证。

　　但是有一些严重的安全错误没有关联到标准或配置。事实上，每当它们让老错误重新发生的时候，Web服务并没有引入新型的安全顾虑。如果遗留系统拥有一个全新的Web服务接口，曾经深藏在系统中的各种各样的问题现在可能找到它们出口。通过直接向网络公开曾经是程序内部工作方式，程序员可能不经意的忽视输入验证或访问控制机制，开放太多程序内部的工作方式，或为会话管理错误提供一个新的讨论区。