在第一部分的文章中，我们讨论了如何在一个WSDL文件中以关闭操作列表的方式来生成SOAP请求，以及怎样将这套流程通过Ruby及Burp套件自动加以执行。此外，我们还介绍了WSDL文件内容的解析方式。在本文中，我们将要对SOAP服务中的一系列安全漏洞进行测试及利用。并不是所有的攻击行为都针对SOAP，我们必须对这一情况具备清醒的认识。
这一行的新手往往有种先入为主的观念，认为威胁网页服务安全的各类攻击总带有一些神秘色彩并且超难阻止。但实际情况是，网页服务遭受的许多侵袭都源自与浏览器应用程序安全缺陷相类似的同一种漏洞。
举例来说，大家会发现各类认证标准损坏及会话管理缺陷都包含在我们下面这份漏洞列表中。看起来眼熟吧？眼熟就对了，因为这正是我们原先曾向大家介绍过的OWASP十大漏洞排名，而事实上这些问题对网页应用程序及网页服务都将构成同等威胁。
我们在本文中打算讲解并利用的漏洞类型分别为：
1. SOAP 注入
2. SQL 注入
3. 默认内容
4. 破损的认证及会话管理
SOAP 注入
虽然网页服务方面的许多安全缺陷都有相似之处或者几乎同样为大众所熟知，而且这些漏洞不仅被编纂成文供人们参考，甚至要将其真正利用起来也不需要什么高超的技术。但SOAP注入有所不同，它所指向的弱点不仅难于抵御，对攻击者的水平也有相当的要求。
那么这种攻击到底是如何发生的？服务器端的XML解析引擎从客户端接收输入信息，这里指的客户端可以是浏览器、来自网页应用程序的数据、一部移动设备或者是其它类型的来源。如果不对输入的信息进行正确验证，接收的结果就很可能出现错误，进而为攻击行为提供了便利。
基于上述情况，我们就从攻击者的立场出发，在不具备高超技术或是对SOAP请求服务器端处理方式的深入了解的前提下，一步步接近SOAP注入攻击的真实流程。这要求我们首先准备一些极度冗长的错误信息（听起来可能有点像安全配置失误）。
请遵循下列要求：
请求显示正常。我们在此发出自己的姓名及密码，如果请求接下来也同样发送正常，则解析工作同样会顺利进行。在此，我们能否被授予访问权限取决于初始时提交何种内容的请求。
现在让我们生成一个同样的请求，但这一次省略掉
| <lname></lname> |
标签。
根据下图显示的服务器响应结果可以看出，我们应该是已经取得了某些突破：
这个错误警告实际上向我们间接交代出了代码！我们看到的这条故障提示的实际表意是如果缺少lname变量，那么代码应该利用登录ID参数作为替代。现在的事态很有趣。在这种情况下，我们要做的是刻意省略lname标签以触发故障提示（"II"），进而提取登录ID标签。
这是我们创建的新请求：
好了，现在出现的提示信息如下：
这意味着我们需要利用已经收集到的授权证书或信息启动执行操作
(提交
| <loginid>1</loginid> |
标签)。
此类攻击方式相对比较简单，利用到的是编写在背景中的、包含错误信息的简陋解析引擎。如此一来，我们提交的请求就会被作为来自管理员级别账户的操作被加以接收。#p#
SQL注入
在这部分内容中，我们将用到在第一部分文章中创建的一些代码。启动附有Ruby脚本的Burp，该脚本名称为attack_soap.rb。
让我们向WSDL文件发送一条请求，在Burp处实施拦截，生成请求然后将其进行模糊处理及分析。打完收功。
正如第一部分文章中提到的，上述步骤会自动生成一条要求关闭WSDL文件中操作及参数的SOAP请求。在attack_soap.rb脚本中，我们已经编写了特殊的SOAP请求并传递至Burp代理。一旦该请求生成并被正确拦截，我们就能将在攻击中让其发挥作用。
通过对侵入活动的定位，我们接下来需要编写打算插入的模糊字符串。
请注意，我们对101在插入点中进行了渗透，因此我们的模糊字符串将取代整数"101"的位置。
现在要做的是选择有效荷载。Fuzzdb是模糊字符串的上佳来源，我们可以从以下网络中找到任何能在本教程的Burp有效荷载创建方面派上用场的内容：http://code.google.com/p/fuzzdb/。
选择预设的下拉列表；在下拉列表中添加选择"fuzzing-full"荷载。
开始攻击，如下图所示：
现在我们需要审查来自应用程序的响应信息。请注意，虽然多数的返回响应都是总长度为634的单字节内容，但字符串"1 or 1=1--"返回的却是总长度为1662的单字节内容。
这背后可能有什么玄机，让我们拭目以待。
应用程序已经通过回馈信用卡列表的形式响应SQL语句！到此我们利用SOAP服务中的SQL注入漏洞计划获得了圆满成功，掌声鼓励。#p#
默认内容寻获
分析此类漏洞的重点在于提醒各位读者，正如传统网页应用程序的默认内容暴露会引发安全威胁，服务器托管型网页服务也具有同样的特性。
作为攻击者，大家应该尽最大努力挖掘那些网页开发人员或管理员忘记删除的任何隐藏或看似无用的内容。一般来说我们总能发现些没有经过正确测试或是包含关键性漏洞的代码。此外，这类文件还可能以某种文本文档或Excel表格形式存储起来的验证信息或其它敏感资源。
通常情况下，我们"至少"应该运行下列Google查询内容（这些内容并不全面，大家还需要自己加以补充）：
上述查询所返回的全部文件都与我们提供的站点名称相匹配。在大家使用SOAP时，强烈建议各位将添加"filetype:wsdl"作为寻获站点中额外wsdl文件的首选方案。
到这一步还不算完。SVNDigger会列出一份庞大的目录，内容涵盖各类可以用来寻获默认内容的目录及文件名称。大家可以在http://www.mavitunasecurity.com/blog/svn-digger-better-lists-for-forced-browsing/处下载这份关键词检索表，不过我们通过intruder加载模糊列表的形式已经达到了与使用SVNDigger检索表相同的目的。
大家同样可以选择使用OWASP推荐的"DirBuster"工具，并以此种方式加载检索表。
需要重申的是，暴露在外的默认内容可能会导致由敏感性数据外泄引发的各类严重危害。大家在实践这类攻击方式时务必谨慎再谨慎，否则可能会带来灾难性的后果。
损坏的验证及会话管理缺陷
这种类型的漏洞对于网页服务的影响与对传统网页应用程序的影响是相同的。事实上，随着移动设备的迅猛崛起，网页服务也开始对其提供支持。而且我们身边遭遇此类漏洞威胁的事例也在不断增加。#p#
每条请求中用户名及密码的提交
以SOAP请求为例，该请求需要得到上级WSDL的基本授权。这种存在于应用程序及用户浏览器之间的授权标准具备如下交互过程：
1. 用户提交验证信息
2. 应用程序验证该信息，并发送一个cookie
3. 用户浏览器存储来自应用程序的这个cookie值
4. 根据来自用户浏览器的后续请求，该cookie会被再次发往应用程序端
有了这种基本的流程概念，即使那些cookie是窃取来的，在其过期之前应该还是可以奏效一段时间。但如果想要获取更多信息以查看或修改密码，攻击者只能凭借自己的运气。
然而当下太多的移动应用程序利用基本信息验证与网页服务进行交互，因此我们常常会发现有些移动应用会在每个发往网页服务的请求中都夹带验证信息！
如果用户的手机处于开机状态并连入允许公开访问的Wi-Fi网络，而网页服务使用的又不是HTTPS协议，这就意味着整个传输过程利用的负载媒介相当于纯文本。让我们探究一下破解基本验证信息到底有多容易。
将基本验证信息字符串发送至Burp解码器
正如大家所见，用户名为guest，而密码也为guest。在这里我再次强调，移动应用程序中时刻充斥着这类简单漏洞。
缺乏账号锁定机制
输入一定次数的错误口令后，账号仍未转为锁定状态，这是当前网页服务中另一个很常见的缺陷。也就是说攻击者完全可以通过暴力破解的方式获得用户名与密码的组合。此种不必要的失误很有可能给服务账号带来极大的安全威胁，值得我们认真对待。
密码复杂性过低
当大家在将上述安全隐患（例如缺乏账号锁定机制）纳入解决日程时，也别忘了同时提高密码复杂性。一旦出于好记的目的而将密码设置得过分简单，这就构成了新的安全缺陷，未经授权的恶意攻击者也很快会趁虚而入。
总结
正如大家所看到的，已经存在且尽人皆知的网页应用程序安全漏洞同样肆虐于网页服务领域。导致攻击或渗透出现的前提在细节上可能各有不同，但本质在根源上是相通的，即安全设计上的缺陷加之实际编码中的疏漏。
希望本文能为用于识别及应对网页服务、尤其是SOAP网页服务领域安全弱点的各类技术提供一些启示。
原文链接：http://resources.infosecinstitute.com/soap-attack-2/
