用APPCAN 测试web services之1

转载

前言

近年来Web服务应用日趋广泛，人们往往利用Web服务集成不同平台的应用程序，或是将公共服务通过服务接口暴露给外部用户使用。然而，新技术往往同时带来新风险。由于Web服务直接暴露了应用程序的服务接口，且穿越了防火墙的控制，黑客可以利用Web服务攻击企业应用。本文旨在帮助读者识别Web服务常见安全漏洞，了解如何规避这些安全漏洞，同时结合案例跟读者分享如何利用Rational AppScan检测Web服务的安全漏洞。

Web服务安全简介

Web服务技术实现了应用程序之间的跨平台、跨编程语言通信，其最基本的组成部分为服务的提供者（Service Provider）和服务的请求者（Service Requester）。两者通过基于标准的XML格式的协议进行通信的，这种最常用的协议就是SOAP（Simple Object Access Protocol）。按照Web服务的相关标准描述，服务的提供者应该首先通过WSDL（Web Service Definition Language）和UDDI（Universal Description, Discovery, and Integration）发布它所提供的服务到一个统一注册这些服务信息的存储库中去。这样，服务的请求者就可以通过WSDL和UDDI发现服务提供者提供的服务，并通过应用的调用方法来使用这个服务。

对于任何应用程序来说，保护信息访问的安全都是最基本的要求。在面向服务体系架构（Service Oriented Architecture，SOA）原则构造的复杂系统环境中，Web服务扮演着各个系统组件之间的协调员的角色，因此Web服务的安全性尤为重要。Web服务客观需要业界统一的安全规范体系，使各种系统能够以一个与平台和语言无关的方式安全地互相操作。

结合Web服务的技术特性，下文我们从传输层、消息层及应用层进行了解Web服务安全相关技术及特点。

传输层安全

目前绝大多数Web服务实现主要采用了基于HTTP的SOAP协议。HTTP协议在安全性方面相当薄弱。HTTP协议只提供一种身份确认的认证方法，它不提供数据隐私及数据完整性方面的保护。因此，对于基于HTTP的Web服务来说，我们应尽量采用安全套接字层（Secure Sockets Layer，SSL）来保障传输数据的安全。安全套接字层协议在客户机和服务器之间建立了一条安全的信息隧道，一个加密的SSL连接要求所有在客户机和服务器之间传输的信息都由发送软件加密，由接收软件解密，这样就提供了高度的机密性（数据隐私）。此外，所有在加密SSL连接上传输的数据都由一个自动数据完整性机制保护，确保数据在传输过程中未经更改。

这样，通过SSL我们能保障传输数据的认证、数据完整性及保密性。但SSL并不能解决所有的问题，SSL仅仅保障数据传输过程中的数据安全，也不能解决消息层面所面临的安全问题。

消息层安全

2002年IBM和Microsoft发布了一个联合的安全性白皮书“Security in a Web Services World：A Proposed Architecture and Roadmap”。它定义了一个全面的Web服务安全性模型，该模型对几个流行的安全性模型、机制和技术（同时包括对称密钥技术和公钥技术）加以支持、集成和统一，使各种系统能够以一个与平台和语言无关的方式安全地互相操作。它还描述了一组规范和方案，指出应怎样将这些规范一起使用。

Web服务安全性(WS-Security)规范主要致力于提供消息层面的安全机制，在实现上主要在SOAP中通过XML Signature、XML Encryption和Security Tokens（譬如UsernameToken、X.509 Certificates、SAML等）保障消息的安全性。Web服务的安全性协议体系以WS-Security规范为基础，有六个主要的组成规范：

• Web服务策略(WS-Policy)和相关的规范，定义了关于服务交互方式的策略规则。
• Web服务信任(WS-Trust)，定义了安全交换的信任模型。
• Web服务隐私(WS-Privacy)，定义了如何维护信息的隐私。
• Web服务安全会话(WS-Secure Conversation)，定义了如何使用在Web服务策略(WS-Policy)、Web服务信任(WS-Trust)和Web服务隐私(WS-Privacy)中定义的规则，以在用于交换数据的服务之间建立安全会话。
• Web服务联盟(WS-Federation)，定义了分布式标识的规则以及如何对其进行管理。
• Web服务授权(WS-Authorization)，定义了如何处理对访问和交换数据的授权。

简而言之，WS-Security通过消息完整性、消息机密性和消息认证及一些扩展模型保障了SOAP消息安全传递。但WS-Security并不能解决应用层面的安全问题。此外，Web服务基于XML的特性还导致Web服务可能存在着XML相关的安全漏洞，譬如XPath注入、XML解析相关的拒绝服务攻击（Denial of Service，DoS）等。

应用层层安全

很多人误以为Web服务没有界面，黑客就无法进行攻击。事实上，Web服务通常仅是对现有应用层功能进行了封装，其后台应用层代码如果存在安全漏洞，黑客完全可以使用Web服务进行攻击这些漏洞。绝大多数情况下，Web服务默认都支持WSDL的发布服务，黑客可以轻松获取WSDL从而了解Web服务提供的操作及SOAP消息格式，这使得攻击变得尤为简易。所以说，Web应用中所面临的安全威胁同样存在于Web服务中。

因此，我们要走出误区，SSL和WS-Security并不能解决所有的安全问题，SQL注入、XSS等Web层的常见安全漏洞同样可能存在于我们的Web服务中。Web服务的安全不仅仅是传输层、消息层的安全，还要关注Web服务背后应用层代码中的安全漏洞。这需要开发团队从需求、编码、测试及部署等各个阶段进行预防、检测及修复，全面保障Web服务的安全。

回页首

Web服务常见安全漏洞

前文介绍了Web服务安全相关基础技术，掌握以上知识不代表就能开发出安全的Web服务。俗话说“知己知彼，百战不殆”，作为应用开发/测试人员，我们除了掌握Web服务安全相关知识外，还应了解常见安全漏洞原理，这样才能够根据具体应用实际情况，因地制宜地进行安全建模、风险评估及安全测试等工作。

正如前文所分析的，Web服务安全漏洞主要包括常见Web应用安全漏洞，以及XML相关的特殊安全漏洞。其中Web服务相关的应用层漏洞包括有命令注入（SQL、LDAP、OS Command）、缓冲区溢出、不正确的异常处理、无效的访问控制等。XML相关的安全漏洞主要有命令注入（XPath、XQuery）、拒绝服务攻击（SOAP数组溢出、递归的XML实体声明、超大消息体）以及信息泄漏（XML External Entity File Disclosure）等。鉴于篇幅所限，下文将选择其中最常见的几个漏洞进行剖析，以飨读者。

XPath注入

SQL注入是大家所熟知的安全漏洞，同样的原理，XPath作为用来查询XML数据的语言，同样容易存在很多注入漏洞。某种程度来说，XPath注入比SQL注入更简单，因为不同数据库产品的SQL语句有不同的方言，而XPath相对比较标准。我们假定某Web服务后台采用了这段代码来查询某XML数据文件中的记录。

清单1.存在注入漏洞的XPath查询

其中username和password是通过SOAP消息进行传输，如下文：

清单2.传递XPath查询参数的SOAP消息片段

假如黑客利用SOAP传入 username="admin", password="' or '1'='1"，以上XPath查询就变为：

清单3.遭注入的XPath查询

这样黑客即可实现特权升级，访问到admin用户信息。

拒绝服务攻击

由于Web服务基于XML格式的协议进行通信（例如SOAP消息）。当SOAP消息到达Web服务器段时，服务器端会调用XML Parser解析XML数据（包括DTD声明），黑客可以利用大量的超大消息体或者递归的XML实体声明，让服务器端长时间解析XML数据，直至服务器资源耗竭，从而形成拒绝访问攻击，导致Web服务停止服务。

例如，SOAP消息中可以加入以下大量无意义的实体声明，导致SOAP消息解析缓慢。

清单4. SOAP消息中无意义的实体声明示例

信息泄漏

某些Web服务会返回客户端指定的资源信息时，如果服务器端防范不当，则可能存在信息泄漏隐患。举个简单的类似HelloWorld的例子，假设某个Web服务会接受用户传来的名字“Jeremy”，然后返回“Hello, Jeremy!”。但，如果黑客传入如下参数：

清单5. SOAP消息中声明外部文件引用

服务器端如果疏于参数校验及文件访问权限控制，该Web服务可能返回系统文件的内容。

回页首

Web服务安全推荐实践

显而易见，开发安全的Web服务是一项系统而复杂的工作。实际项目中Web服务的开发往往依赖于一些框架及中间件。因此如何开发安全的Web服务，需要结合各个框架和中间件进行具体分析。目前DeveloperWorks中有大量的资料，读者可自行研读，本文不再就此深入。下文笔者仅结合自己项目经历，就开发安全的Web服务所需要注意的一些事项，给大家共享一些实践经验，以供参考。

概而言之，开发安全的Web服务包括三个步骤：1、识别需要保护的Web服务资源；2、从传输层、消息层、应用层考虑安全设计；3、利用渗透测试检测安全漏洞并修复。

识别需要保护的Web服务资源

首先我们应评估需要保护的Web服务，了解它潜在的安全风险，整理其安全需求，作为后期的设计实现的基础。以下是笔者整理的检查清单，评估工作具体可以通过回答这些问题来进行整理。

• 访问Web服务是否需要认证？
• 是否需要检查服务请求者对Web服务的访问权限？
• Web服务是否接受请求者传递的参数？
• 这些参数是否可行&如何校验？
• Web服务请求/响应的消息体是否包括敏感信息？
• Web服务的消息体如何传输&如何存储？
• Web服务的数据在传输/存储时是否需要加密处理？
• Web服务的后端程序是否跟其他第三方应用存在交互，这个过程是否可行？

利用以上这些评估工作的结果，最终形成Web服务的安全需求。

从三个层面进行综合安全设计

Web服务设计开发过程中，需要将步骤一形成的安全需求落实到系统设计和编码实现中去。如果采用了基于HTTP的SOAP消息传输，我们推荐使用SSL保障传输层的安全。对于受保护的Web服务资源，建议通过Security Token保障消息的认证访问；对于敏感信息，建议使用XML Encryption进行加密；推荐使用XML Signature保障消息的完整性。具体编码过程中，需要遵循安全编程的原则，譬如参数的校验和转码、异常的封装处理等。推荐在开发阶段使用代码分析工具进行白盒安全检查。

利用渗透测试进行检测

Web服务部署过程中，我们推荐使用XML网关（譬如WebSphere DataPower Service Gateway）保障XML通信的安全。XML网关通常处于外部网络与目标系统之间，解析接收到的XML信息流，并利用XML Schema、WSDL等判断XML消息是否符合要求，并根据检测及判断结果执行访问控制规则，将可信的合法信息流向目标系统，将非法信息进行阻截。因此，XML网关有助于过滤Web服务所面临的XML相关的安全漏洞。

此外，系统部署阶段，我们推荐进行渗透测试，作为最后一道安全措施，进一步保障Web服务的安全性。IBM Rational AppScan Standard（下文简称为AppScan）产品是业界领先的Web应用安全测试工具，它提供了集成的“通用服务客户机(GSC)”，能基于WSDL探索Web服务，并结合测试策略库针对常见Web服务安全漏洞自动生成测试变体，自动执行这些测试变体并生成测试报告，从而实现自动化渗透测试。

Altoro Mutual是IBM所提供的Web安全漏洞演示网站，下文笔者将向读者展示如何利用AppScan来检测该网站所存在的Web服务安全漏洞。考虑到SoapUI是大家熟悉的Web服务测试工具，本文将同时介绍如何结合SoapUI和AppScan进行检测Web服务安全漏洞。

回页首

利用AppScan GSC检测Web服务安全漏洞

1. 选择“常规扫描”模板，新建扫描。