使用 Rational AppScan 检测 Web services 安全漏洞.docx

使用 Rational AppScan 检测 Web services 安全漏洞.docx

《使用 Rational AppScan 检测 Web services 安全漏洞.docx》由会员分享，可在线阅读，更多相关《使用 Rational AppScan 检测 Web services 安全漏洞.docx（11页珍藏版）》请在冰豆网上搜索。

使用RationalAppScan检测Webservices安全漏洞

使用RationalAppScan检测Webservices安全漏洞

近年来Web服务（Webservices）应用日趋广泛，人们往往利用Web服务集成不同平台的应用程序，或是将公共服务通过服务接口暴露给外部用户使用。

然而，新技术往往同时带来新风险。

由于Web服务直接暴露了应用程序的服务接口，且穿越了防火墙的控制，黑客可以利用Web服务攻击企业应用。

本文旨在帮助读者识别Web服务的常见安全漏洞，了解如何规避这些安全漏洞，同时结合案例跟读者分享如何利用RationalAppScan检测Web服务的安全漏洞。

0 评论：

何健,高级软件工程师,IBM

2012年1月09日

∙内容

下载试用版：

IBM®Rational®AppScan标准版  |  Web应用安全与IBMRationalAppScan工具包

下载更多的 IBM软件试用版，并加入 IBM软件下载与技术交流群组，参与在线交流。

前言

近年来Web服务应用日趋广泛，人们往往利用Web服务集成不同平台的应用程序，或是将公共服务通过服务接口暴露给外部用户使用。

然而，新技术往往同时带来新风险。

由于Web服务直接暴露了应用程序的服务接口，且穿越了防火墙的控制，黑客可以利用Web服务攻击企业应用。

本文旨在帮助读者识别Web服务常见安全漏洞，了解如何规避这些安全漏洞，同时结合案例跟读者分享如何利用RationalAppScan检测Web服务的安全漏洞。

回页首

Web服务安全简介

Web服务技术实现了应用程序之间的跨平台、跨编程语言通信，其最基本的组成部分为服务的提供者（ServiceProvider）和服务的请求者（ServiceRequester）。

两者通过基于标准的XML格式的协议进行通信的，这种最常用的协议就是SOAP（SimpleObjectAccessProtocol）。

按照Web服务的相关标准描述，服务的提供者应该首先通过WSDL（WebServiceDefinitionLanguage）和UDDI（UniversalDescription,Discovery,andIntegration）发布它所提供的服务到一个统一注册这些服务信息的存储库中去。

这样，服务的请求者就可以通过WSDL和UDDI发现服务提供者提供的服务，并通过应用的调用方法来使用这个服务。

对于任何应用程序来说，保护信息访问的安全都是最基本的要求。

在面向服务体系架构（ServiceOrientedArchitecture，SOA）原则构造的复杂系统环境中，Web服务扮演着各个系统组件之间的协调员的角色，因此Web服务的安全性尤为重要。

Web服务客观需要业界统一的安全规范体系，使各种系统能够以一个与平台和语言无关的方式安全地互相操作。

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

传输层安全

目前绝大多数Web服务实现主要采用了基于HTTP的SOAP协议。

HTTP协议在安全性方面相当薄弱。

HTTP协议只提供一种身份确认的认证方法，它不提供数据隐私及数据完整性方面的保护。

因此，对于基于HTTP的Web服务来说，我们应尽量采用安全套接字层（SecureSocketsLayer，SSL）来保障传输数据的安全。

安全套接字层协议在客户机和服务器之间建立了一条安全的信息隧道，一个加密的SSL连接要求所有在客户机和服务器之间传输的信息都由发送软件加密，由接收软件解密，这样就提供了高度的机密性（数据隐私）。

此外，所有在加密SSL连接上传输的数据都由一个自动数据完整性机制保护，确保数据在传输过程中未经更改。

这样，通过SSL我们能保障传输数据的认证、数据完整性及保密性。

但SSL并不能解决所有的问题，SSL仅仅保障数据传输过程中的数据安全，也不能解决消息层面所面临的安全问题。

消息层安全

2002年IBM和Microsoft发布了一个联合的安全性白皮书“SecurityinaWebServicesWorld：

AProposedArchitectureandRoadmap”。

它定义了一个全面的Web服务安全性模型，该模型对几个流行的安全性模型、机制和技术（同时包括对称密钥技术和公钥技术）加以支持、集成和统一，使各种系统能够以一个与平台和语言无关的方式安全地互相操作。

它还描述了一组规范和方案，指出应怎样将这些规范一起使用。

Web服务安全性（WS-Security）规范主要致力于提供消息层面的安全机制，在实现上主要在SOAP中通过XMLSignature、XMLEncryption和SecurityTokens（譬如UsernameToken、X.509Certificates、SAML等）保障消息的安全性。

Web服务的安全性协议体系以WS-Security规范为基础，有六个主要的组成规范：

∙Web服务策略（WS-Policy）和相关的规范，定义了关于服务交互方式的策略规则。

∙Web服务信任（WS-Trust），定义了安全交换的信任模型。

∙Web服务隐私（WS-Privacy），定义了如何维护信息的隐私。

∙Web服务安全会话（WS-SecureConversation），定义了如何使用在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解析相关的拒绝服务攻击（DenialofService，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、OSCommand）、缓冲区溢出、不正确的异常处理、无效的访问控制等。

XML相关的安全漏洞主要有命令注入（XPath、XQuery）、拒绝服务攻击（SOAP数组溢出、递归的XML实体声明、超大消息体）以及信息泄漏（XMLExternalEntityFileDisclosure）等。

鉴于篇幅所限，下文将选择其中最常见的几个漏洞进行剖析，以飨读者。

XPath注入

SQL注入是大家所熟知的安全漏洞，同样的原理，XPath作为用来查询XML数据的语言，同样容易存在很多注入漏洞。

某种程度来说，XPath注入比SQL注入更简单，因为不同数据库产品的SQL语句有不同的方言，而XPath相对比较标准。

我们假定某Web服务后台采用了这段代码来查询某XML数据文件中的记录。

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

Stmt="//users/user[username/text（）='"+username+"'andpassword/text（）='"+password+"']/id/text（）";

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

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

Envelopexmlns:

soap="">

Body>

PerformFunctionxmlns:

fn="">

uid>testuser

uid>

password>testpassword

password>

PerformFunction>

Body>

Envelope>

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

清单3.遭注入的XPath查询

Stmt="//users/user[username/text（）='admin'andpassword/text（）=''or'1'='1']/id/text（）";

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

拒绝服务攻击

由于Web服务基于XML格式的协议进行通信（例如SOAP消息）。

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

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

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

DOCTYPEroot[

ENTITYha"Ha!

">

ENTITYha2"&ha;&ha;">

ENTITYha3"&ha2;&ha2;">...

ENTITYha127"&ha126;&ha126;">

ENTITYha128"&ha127;&ha127;">]>

信息泄漏

某些Web服务会返回客户端指定的资源信息时，如果服务器端防范不当，则可能存在信息泄漏隐患。

举个简单的类似HelloWorld的例子，假设某个Web服务会接受用户传来的名字“Jeremy”，然后返回“Hello,Jeremy!

”。

但，如果黑客传入如下参数：

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

DOCTYPEroot[

ENTITYmyfileSYSTEM"file:

//c:

/windows/win.ini">]>...&myfile;

服务器端如果疏于参数校验及文件访问权限控制，该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服务资源，建议通过SecurityToken保障消息的认证访问；对于敏感信息，建议使用XMLEncryption进行加密；推荐使用XMLSignature保障消息的完整性。

具体编码过程中，需要遵循安全编程的原则，譬如参数的校验和转码、异常的封装处理等。

推荐在开发阶段使用代码分析工具进行白盒安全检查。

利用渗透测试进行检测

Web服务部署过程中，我们推荐使用XML网关（譬如WebSphereDataPowerServiceGateway）保障XML通信的安全。

XML网关通常处于外部网络与目标系统之间，解析接收到的XML信息流，并利用XMLSchema、WSDL等判断XML消息是否符合要求，并根据检测及判断结果执行访问控制规则，将可信的合法信息流向目标系统，将非法信息进行阻截。

因此，XML网关有助于过滤Web服务所面临的XML相关的安全漏洞。

此外，系统部署阶段，我们推荐进行渗透测试，作为最后一道安全措施，进一步保障Web服务的安全性。

IBMRationalAppScanStandard（下文简称为AppScan）产品是业界领先的Web应用安全测试工具，它提供了集成的“通用服务客户机（GSC）”，能基于WSDL探索Web服务，并结合测试策略库针对常见Web服务安全漏洞自动生成测试变体，自动执行这些测试变体并生成测试报告，从而实现自动化渗透测试。

AltoroMutual是IBM所提供的Web安全漏洞演示网站，下文笔者将向读者展示如何利用AppScan来检测该网站所存在的Web服务安全漏洞。

考虑到SoapUI是大家熟悉的Web服务测试工具，本文将同时介绍如何结合SoapUI和AppScan进行检测Web服务安全漏洞。

回页首

利用AppScanGSC检测Web服务安全漏洞

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

图1.新建常规扫描

1.设置扫描类型为“WebService扫描”。

图2.设置WebService扫描类型

1.输入WSDL的访问地址：

图3.设置WSDLURL

1.选择“WebService”测试策略

图4.设置WebService测试策略

1.点击“完成”，AppScan将自动启动通用服务客户机GSC。

图5.完成扫描配置向导

1.GSC启动后，会自动根据提供的WSDL地址，导入WSDL文件，需要稍等片刻。

图6.常规服务客户端GSC自动导入WSDL

1.导入WSDL后，我们可以在左侧看到Web服务所提供的所有操作及对应的SOAP请求。

图7.GSW完成WSDL导入

1.我们选择TransferBalance操作，点击其ServiceSoap，右侧将出现请求SOAP消息的表单，选择“transDetails”，然后输入transferDate，debitAccount，creditAccount及transferAmount等参数，如下图所示，然后点击“调用”按钮。

图8.编辑SOAP请求数据

1.等待并查看Web服务响应。

图9.查看WebService响应

1.关闭GSC，AppScan会自动导入GSC探索到的URL，我们可以在数据视图中查看该URL的请求及响应。

图10.查看GSC探索结果

1.点击“扫描”-“仅测试”，AppScan即自动对当前Web服务的TransferBalance操作进行自动化渗透测试。

结果如下图所示。

图11.查看WebService测试结果

请注意：

∙以上案例，我们仅仅测试了Web服务中的其中一个操作，实际测试中应对所有的操作都进行测试；

∙案例中，我们发现了SQL注入漏洞等常见Web应用漏洞，佐证了Web服务可能存在常见的Web应用安全漏洞；

∙案例中我们使用了默认WebService测试策略，默认WebService测试策略不包括XML解析相关的拒绝服务测试变体，实际测试中应结合项目实际要求定制自己的测试策略。

回页首

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

下面我们使用SoapUI重新探索上述案例，并使用AppScan扫描SoapUI探索的结果。

如果没有安装GSC，用户可以使用这种方案来检测Web服务的安全漏洞。

1.新建常规扫描，设置扫描类型为“Web应用程序扫描”。

图12.新建Web应用扫描

1.输入起始URL：

图13.设置起始URL

1.登录方法选择“无”。

图14.设置登录方法

1.依旧选择“WebService”测试策略。

图15.设置测试策略

1.因为我们将使用SoapUI进行探索，所以这里选择“稍后启动扫描”，然后点击“完成”按钮。

图16.完成向导并稍后启动扫描

1.接下来，我们需要设置SoapUI和AppScan的代理关系。

点击“工具”-“选项”，查看当前AppScan的动态代理端口。

这里，我们将AppScan作为Web代理服务器，因此需要将此代理端口提供给SoapUI。

图17.查看AppScan代理端口

1.打开SoapUI，新建一个SoapUI工程，命名为“AltoroMutual”，WSDL地址设为“

图18.新建soapUI工程

1.SoapUI新建工程过程中，会自动导入WSDL定义。

从下图可以看出，跟GSC类似，SoapUI在左侧展示了Web服务的所有操作及其SOAP格式。

图19.soapUI工程创建完成

1.点击“File”-“Preferences”，进入ProxySettings，设置AppScan作为代理服务器，如下图所示。

端口2979为步骤6中所查看到的端口号。

点击“OK”保存设置。

图20.设置soapUI的代理

1.双击“TransferBalance”下的SOAP请求，右侧会展示SOAP消息体，我们同样输入transferDate，debitAccount，creditAccount及transferAmount等参数，然后点击绿色三角按钮执行该SOAP请求。

图21.修改参数并提交SOAP请求

1.稍等片刻，SoapUI即展示出以上请求的响应信息。

图22.查看WebService响应

1.关闭SoapUI。

AppScan会自动弹出手工探测结果，提醒用户进行确认。

直接点击“确定”。

图23.查看手工探索结果

1.同样进入AppScan数据视图，我们可以看到AppScan探索到了SoapUI所发出的SOAP请求及收到的响应。

图24.AppScan探索结果中的SOAP请求

1.点击“扫描”-“仅测试”，AppScan即自动对当前探索结果进行自动化渗透测试。

以上两个案例的扫描脚本分别保存为“Demo_GSC.scan”、“Demo_SoapUI.scan”，供读者下载比较其配置方式的异同。

回页首

结论

本文介绍了Web服务安全方面的基础知识，结合读者的项目实践，跟读者分享了常见的Web服务安全漏洞，并推荐了读者在实际项目中总结出来的Web服务安全开发相关实践。

Web服务安全的保障工作贯穿于整个软件开发周期中，而渗透测试是保障Web服务安全的最后一道重要关口，笔者向读者演示了如何使用IBMRationalAppScan对Web服务进行渗透测试。

由于见解所限，如有不及之处，欢迎交流，共同提高。