1．XML解析攻击技术

（1）主要攻击方法和攻击点

XML解析器是Web服务支撑环境中的重要组成部分，因为当Web服务接收到SOAP格式的请求后，都会调用XML解析器（因为SOAP也是XML格式的请求包，SOAP解析器实质是XML解析器）来解析SOAP数据包，提取请求包中的变量名及类型等，交给应用服务器处理。在该过程中可以通过构造特殊的SOAP请求数据包来攻击XML解析器，造成应用服务器的服务质量下降或崩溃。

攻击XML解析器的方法主要有两种，即大文件缓冲区攻击和循环嵌套负载攻击。前者主要是向XML解析器发送大量的大文件，如通过多媒体文件等来导致XML解析器处理负载过大；后者主要是通过构造特殊的循环数据包来导致XML解析器消耗大量的资源形成拒绝服务。此类攻击的攻击点和作用点如图6-30所示。

图6-30 XML解析攻击

（2）针对.NET平台的循环嵌套负载攻击

下面以.NET平台为例来讨论XML解析器攻击，.NET平台Framework 1.1支持DTD数据类型定义。DTD数据类型定义是SOAP协议规范的一项内容，规定了XML解析器在解释XML文档时，根据XML文档中的数据类型来解释变量。根据这一特性，可以尝试在正常的SOAP请求中插入特殊的数据类型定义来构造对XML解析器的攻击。

通过不断地试验和尝试，我们发现通过构造如下格式的XML文档可以造成对.NET平台解析器的拒绝服务攻击：

 !ENTITY a1 "&a0;&a0;" !ENTITY a2 "&a1;&a1;" !ENTITY a3 "&a2;&a2;" !ENTITY a4 "&a3;&a3;" !ENTITY a5 "&a4;&a4;" !ENTITY a6 "&a5;&a5;" !ENTITY a7 "&a6;&a6;" !ENTITY a8 "&a7;&a7;" !ENTITY a9 "&a8;&a8;" !ENTITY a10 "&a9;&a9;" !ENTITY a11 "&a10;&a10;" !ENTITY a12 "&a11;&a11;" !ENTITY a13 "&a12;&a12;" !ENTITY a14 "&a13;&a13;" !ENTITY a15 "&a14;&a14;" !ENTITY a16 "&a15;&a15;" !ENTITY a17 "&a16;&a16;" !ENTITY a18 "&a17;&a17;" !ENTITY a19 "&a18;&a18;" !ENTITY a20 "&a19;&a19;" !ENTITY a21 "&a20;&a20;" !ENTITY a22 "&a21;&a21;" !ENTITY a23 "&a22;&a22;" !ENTITY a24 "&a23;&a23;" !ENTITY a25 "&a24;&a24;" ]> &a25; 

根据上面得到的分析结果，只要能够向一个Web服务发送一个包括使用该DTD定义变量的特定XML文档，即可导致SOAP解析器过度消耗CPU和内存资源，因为该文档在解释过程中会造成循环嵌套。

（3）攻击实例效果

了解针对.NET平台XML解析器拒绝服务攻击的原理后，在Windows 2003平台的.NET Framework 1.1 SP1环境下进行攻击测试，步骤如下。

① 实现Web服务实例。

Web服务实例是一个很简单的Web 服务，其中包含一个hello方法。该方法输入参数是一个Man结构，它返回一个字符串。因为对于任何接收SOAP请求的Web服务，都可以通过在SOAP请求中插入附加的信息来进行攻击。因此只需建立一个最简单的服务，然后通过正常的Web 服务应用调用模拟hello方法，同时通过sniffer监听通信过程中的数据包为攻击工具提供数据资源。

② 建立攻击工具。

针对Web服务实例建立攻击工具，该工具应该能够和特定的Web服务建立正常的连接。在发送SOAP请求时发送特殊XML文档，产生攻击效果。

攻击工具名为“SoapClient”，它在建立正常的TCP连接后通过读取head.txt构造HTTP通信的初步过程数据包，通过读取body.txt文件中的内容构造SOAP请求包。如果要进行攻击，只要通过构造特殊的body.txt文件内容即可实现。
攻击工具使用C#语言在Visual Studio.NET 2003下开发。

③ 攻击效果。

实验中，攻击效果通过系统CPU和内存的消耗来体现，如图6-31和图6-32所示。

通过试验可以看到该攻击具有很好的攻击效果。攻击者不需要花费大量的计算，只需构造一个特殊的文本即可耗费大量攻击目标主机资源，造成拒绝服务攻击，因此循环嵌套负载方法是对XML解析器很好的拒绝服务攻击方法。

图6-31 单包攻击效果（解析1个包）

图6-32 多包攻击效果（同时解析3个包）

2．UDDI服务器攻击技术

（1）针对UDDI服务的攻击方法

针对UDDI服务器的攻击在整个Web服务组件部署中的位置，如图6-33所示。

图6-33 UDDI拒绝服务攻击

针对UDDI服务器的攻击技术主要有两种，即拒绝服务攻击和对发布服务消息的篡改。前者需要较少的前提条件；后者则需要能够突破UDDI服务器的认证和访问控制等。

针对UDDI服务器的攻击通常不能直接影响到具体某个应用服务的功能，因为Web服务的消费者在发现某个Web应用服务后就会将其绑定。如果该Web服务的提供位置或功能等没有发生变化，则消费者不需要访问UDDI服务器。但对于整个网格系统来说，UDDI服务器的功能受到影响后会降低整个系统的动态调整能力，从而降低整个系统的可靠性，因此攻击UDDI服务器对整个系统的功能也有重要的影响。

（2）拒绝服务攻击

拒绝服务攻击是影响Web服务可用性的攻击技术，这种攻击技术很难防范。原因在于它看起来同正常的服务调用没有很大的区别，因此很难防范。拒绝服务攻击技术经历了两个发展阶段，即单机拒绝服务攻击和分布式拒绝服务攻击。其中后者造成的影响更大，防范也更为困难。

单机拒绝服务攻击主要利用攻击者和被攻击者之间计算和存储空间等资源的不对等消耗，即服务请求者只需消耗很少的计算或存储资源，而服务提供者则需要耗费大量的计算或存储资源就有可能形成拒绝服务攻击。

攻击者通过寻找这类Web服务，然后不断请求该服务。这样只需消耗很少的计算或存储等资源，使被攻击者消耗大量的资源，从而导致被攻击者服务能力降低，甚至崩溃。在实际的攻击中，攻击者还会通过使用各种方法来降低自己的资源消耗，增加被攻击者的资源消耗。如最初的SYN FLOOD攻击就是利用TCP协议3次握手的正常协议流程，通过只请求不响应的方式导致服务方因得不到响应不能释放占用的资源，从而造成拒绝服务攻击。

分布式拒绝服务攻击与单机拒绝服务攻击相比，更加难以同正常服务区别。其攻击步骤通常是攻击者首先控制大量主机，同时向某一目标来请求服务。这样会造成服务提供者难以处理这样庞大的服务请求，从而导致服务质量下降或崩溃。但这种攻击的前提是攻击者要能提前控制大量的傀儡主机，然后才能发起攻击。

（3）针对UDDI服务器的拒绝服务攻击方法

以微软的UDDI服务器为例，说明具体的拒绝服务攻击过程。

微软的UDDI服务器也是一种Web服务，远程主机通过访问IIS提供的Web服务接口提交发布和查询请求。IIS在收到请求后调用本地托管代码，而本地托管代码通过调用数据库中的存储过程完成相应的操作并返回结果。因此要找到其弱点，需要研究相关数据库的设计、数据库中存储过程和本地托管代码的具体实现。其中本地托管代码在IIS的根目录下的\uddi\webroot\bin目录中，包括uddi.api.dll、uddi.core.dll、uddi.web.dll和uddi.addwebreference.dll等程序集。由于这些程序集是托管代码，因此可以使用Reflector工具逆向工程查看源代码，而数据库中的存储过程可以使用存储过程sp_decrypt解密查看。

研究微软的UDDI服务器中UDDI 2.0 API的具体实现，发现其在具体实现中的脆弱性，主要是发现资源消耗不对称的服务。通过深入研究，发现save_business和get_businessDetail可以最大限度地消耗UDDI服务器端的资源。如save_business中要发布的businessEntity有n个联系人，而每个联系人又有m个地址集，那么调用这个API就会引起m×n次数据库IO操作。同样，如果要发布的businessEntity有n个businessService，而每个businessService又绑定了一个tModel，那么调用这个API就会引起m×n次数据库IO操作。还会对tModel的uuid值进行m×n次检验，因此利用这两个API接口可以构造针对UDDI服务器的拒绝服务攻击。

为了提高拒绝服务攻击的效率，除了尽可能消耗被攻击者的资源外，还应当尽可能地压缩自己的资源消耗。经过实验，发现在调用save_business和get_businessDetail的过程中，可以只发送调用请求，而不接收处理返回信息，UDDI服务器端依然会完成相关的操作。例如，根据UDDI 2.0的API规范，远程主机调用save_business，服务器端在成功发布businessEntity后会返回一个businessDetail。但实际上，即使远程主机不接收该businessDetail，这个发布过程依然可以完成。所以可以绕开微软提供的UDDI SDK，而基于socket实现两个接口。利用这两个接口在调用save_business和get_businessDetail时不接收处理返回信息，从而实现对微软的UDDI服务器进行拒绝服务攻击。

（4）攻击效果

构造拒绝服务攻击程序即可在相应的测试环境下进行攻击测试，图6-34和图6-35分别是单机拒绝服务攻击中攻击主机和被攻击的UDDI服务器之间的资源消耗对比。测试主机是两台同样型号的联想PC，启动攻击程序后攻击主机的系统资源消耗开始时比较大。

攻击主机在很短的时间后系统资源消耗很低，而UDDI服务器的系统资源消耗增加很多，而且持续保持。

除系统资源消耗测试外，还测试了UDDI服务器的访问等待时间在攻击前后的差异。试验测试结果为在攻击前，从远程访问UDDI服务器的平均时间为120ms左右，访问等待时间为毫秒级。攻击后，从远程访问UDDI服务器的评价时间为200s左右，访问等待时间为秒级。攻击前后的等待时间提高了3个数量级。因此该拒绝服务攻击虽未完全导致UDDI服务器的崩溃，但也得到了比较好的攻击效果，并且攻击者的资源消耗也比较小。如果通过多台机器同时发动分布式攻击，则能够取得更好的攻击效果。

图6-34 攻击者资源消耗

图6-35 UDDI服务器资源消耗

3．其他针对支撑环境的攻击技术

（1）Schema毒化攻击

当解析一个XML文档时，XML Schemas为解析器提供了格式说明，所有出自OASIS的标准XML语法都使用Schemas。由于这些Schemas描述了必需的预处理说明，因此很容易被毒化攻击。一个攻击者会试图修改或替换保存的Schema来进行攻击，如果Schema被攻击，则很容易造成拒绝服务攻击。

除此之外，如果数据的类型被篡改，也为数据篡改提供了手段。如一个应用执行算术运算时将日期类型改变为数字类型，或修改编码使得解析器无法解析数据。最终通过解析器可构成攻击，这种攻击类似于unicode攻击。

（2）SOAP路由混淆攻击

WS-Routing描述提供了一种指引XML通过复杂环境的方法，允许XML路径中的中间节点在一个XML文档中添加路由信息。如果Web服务通路中有一个站点变节，则会在中间修改路由信息，从而造成拒绝服务或信息泄露。