image.png

一、Web Service基础

Web Service简介

Web Service是一个平台独立的、低耦合的、自包含的、基于可编程的Web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的交互操作的应用程序。

Web Service技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。

Web Service的本质，就是通过网络调用其他网站的资源。Web Service架构的基本思想，就是尽量把非核心功能交给其他人去做，自己全力开发核心功能。

更简单地说，Web Service是一种跨编程语言、跨操作系统平台的远程调用技术。

Web Service基本原理

Web Service通过HTTP协议发送请求和接收结果时，发送的请求内容和结果内容都采用XML格式封装，并增加了一些特定的HTTP消息头，以说明HTTP消息的内容格式，这些特定的HTTP消息头和XML内容格式就是SOAP协议规定的。

Web Service服务器端首先要通过一个WSDL文件来说明自己有什么服务可以对外调用。WSDL就像是一个说明书，用于描述Web Service及其方法、参数和返回值。WSDL文件保存在Web服务器上，通过一个URL地址就可以访问到它。客户端要调用一个Web Service服务之前，要知道该服务的WSDL文件的地址。Web Service服务提供商可以通过两种方式来暴露它的WSDL文件地址：1.注册到UDDI服务器，以便被人查找；2.直接告诉给客户端调用者。

Web Service交互的过程就是，Web Service遵循SOAP协议通过XML封装数据，然后由HTTP协议来传输数据。

【技术干货文档】

Web Service分类

一般的，Web Service分为：

• SOAP型Web Service：SOAP型Web Service允许使用XML格式与服务器进行通信；
• REST型Web Service：REST型Web Service允许使用JSON格式（也可以使用XML格式）与服务器进行通信。与HTTP类似，该类型服务支持GET、POST、PUT、DELETE方法。不需要WSDL、UDDI；

Web Service三要素

Web Service三要素包括SOAP（Simple Object Access Protocol）、WSDL（WebServicesDescriptionLanguage）、UDDI（UniversalDescriptionDiscovery andIntegration）。其中SOAP用来描述传递信息的格式， WSDL用来描述如何访问具体的接口， UDDI用来管理、分发、查询Web Service 。

Web Service相关技术

SOAP

SOAP（Simple Object Access Protocol）简单对象访问协议是交换数据的一种协议规范，是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，它被设计成在WEB上交换结构化的和固化的信息。SOAP不是Web Service的专有协议。

SOAP使用HTTP来发送XML格式的数据，可以简单理解为：SOAP = HTTP +XML

SOAP结构如图：

image

包括以下元素：

• 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息
• 可选的 Header 元素，包含头部信息
• 必需的 Body 元素，包含所有的调用和响应信息
• 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息

image

REST

REST（Representational State Transfer）即表述性状态传递，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

REST是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML（标准通用标记语言下的一个子集）以及HTML（标准通用标记语言下的一个应用）这些现有的广泛流行的协议和标准。

在三种主流的Web服务实现方案中，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的Web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。

WSDL

WSDL（Web Services Description Language）即网络服务描述语言，用于描述Web服务的公共接口。这是一个基于XML的关于如何与Web服务通讯和使用的服务描述；也就是描述与目录中列出的Web服务进行交互时需要绑定的协议和信息格式。通常采用抽象语言描述该服务支持的操作和信息，使用的时候再将实际的网络协议和信息格式绑定给该服务。

WSDL给出了SOAP型Web Service的基本定义，WSDL基于XML语言，描述了与服务交互的基本元素，说明服务端接口、方法、参数和返回值，WSDL是随服务发布成功，自动生成，无需编写。少数情况下，WSDL也可以用来描述REST型Web Service。SOAP也是基于XML（标准通用标记语言下的一个子集）和XSD的，XML是SOAP的数据编码方式。

WADL

WADL（Web Application Description Language）即Web应用程序描述语言，是一个可用计算机处理的表达基于HTTP的Web应用（如RESTWeb服务）的XML词汇。WADL描述了Web服务提供的资源及他们的联系。WADL试图简化重用基于HTTP架构的Web服务。它是一个平台，且与语言无关，并试图推动除Web浏览器的基本使用外的应用重用。

WADL于2009年8月31日由Sun微系统提交至万维网联盟，但联盟目前没有标准化它的计划并且它并没有被广泛地支持。WADL依照描述基于SOAP的RPC式服务的XML词汇WSDL定义，用于描述REST服务，而WSDL也可用于描述RESTWeb服务。

WADL主要用于REST基础。

WADL与WSDL的区别：

• WSDL是面向接口的描述，WADL是面向资源的描述；
• WADL是基于HTTP的，WSDL 2.0是接口独立的；

UDDI

UDDI（Universal Description Discovery and Integration）即统一描述、发现和集成，是一种用于描述、发现、集成Web Service的技术，它是Web Service协议栈的一个重要部分。通过UDDI，企业可以根据自己的需要动态查找并使用Web服务，也可以将自己的Web服务动态地发布到UDDI注册中心，供其他用户使用。

UDDI是核心的Web服务标准之一。它通过SOAP进行消息传输，用Web服务描述语言描述Web服务及其接口使用。

SOAP型Web Service服务架构

如图，Web Service服务提供方将自己的Web服务通过SOAP动态地发布到UDDI注册中心，其中是以WSDL文件来进行描述，Web Service服务消费方先向UDDI注册中心通过SOAP请求WSDL文件回来解析服务提供方提供哪些方法后，再和提供方建立XML格式的HTTP通信：

image

WSDL文档结构

WSDL文档结构如下，以本地WSDL文档为例，：

image

标签说明：

• definitions：所有WSDL文档的根元素都是definitions元素；
• types：数据类型(标签)定义的容器，里面使用schema定义了一些标签结构供message引用 ；
• message：通信消息的数据结构的抽象类型化定义。引用types中定义的标签；
• operation：对服务中所支持的操作的抽象描述，一个operation描述了一个访问入口的请求消息与响应消息对；
• portType：对于某个访问入口点类型所支持的操作的抽象集合，这些操作可以由一个或多个服务访问点来支持；
• binding：特定端口类型的具体协议和数据格式规范的绑定；
• service：相关服务访问点的集合
• port：定义为协议/数据格式绑定与具体Web访问地址组合的单个服务访问点；

那么我们一般如何阅读WSDL文件呢？——WSDL文档都是从下往上阅读的。

先看最底下的service标签，查看其中port标签的binding属性值，然后通过值查找上面的binding标签：

image

通过binding标签可以获得具体协议等信息，然后查看binding的type属性：

image

通过binding的type属性，查找对应的portType，可以获得可操作的方法和参数、返回值等：

image

通过portType下的operation标签的message属性，可以向上查找message获取具体的数据参数：

image

二、编写Web Service程序

简单看下各语言怎么编写Web Service程序。

Java版

编写接口类ICalculator，其中声明两个方法，注意接口要用@WebService修饰：

image

编写接口实现类CalculatorImpl，其中重写实现两个方法，在@WebService修饰中指定端点接口为com.mi1k7ea.ICalculator且服务名为Calcutator：

package com.mi1k7ea;
import javax.jws.WebService;
@WebService(endpointInterface = "com.mi1k7ea.ICalculator", serviceName = "Calcutator")public class CalculatorImpl implements ICalculator {    @Override    public int add(int a, int b) {        return a + b;    }
    @Override    public String concat(String a, String b) {        return a + b;    }}

编写Web Service服务端，通过Endpoint.publish()函数来发布指定地址上的Web Service服务：

import com.mi1k7ea.CalculatorImpl;
import javax.xml.ws.Endpoint;
public class WebService {    public static void main(String[] args) {        System.out.println("[*]Start Web Service...");        CalculatorImpl calculator = new CalculatorImpl();
        String address = "http://127.0.0.1:8081/calculator";        Endpoint.publish(address, calculator);
        System.out.println("[*]Web Service is working...");    }}

运行服务即可访问：

image

三、搜索Web Service服务

Google Hack

filetype:asmx inurl:(_vti_bin | api | webservice | ws )allinurl:dll?wsdl filetype:dll
inurl:jws?wsdlinurl:asmx?wsdlinurl:aspx?wsdlinurl:ascx?wsdlinurl:ashx?wsdlinurl:dll?wsdlinurl:exe?wsdlinurl:php?wsdlinurl:pl?wsdlinurl:?wsdlfiletype:jwsfiletype:asmxfiletype:ascxfiletype:aspxfiletype:ashxfiletype:dllfiletype:exefiletype:phpfiletype:plfiletype:wsdl

通过代理流量筛选

可以在如BurpSuite这种代理工具中设定的过滤规则来筛选Web Service请求。比如“.dll?wsdl”、“.ashx?wsdl”、“.exe?wsdl”、“.php?wsdl”等。

四、针对Web Service的渗透测试

Web Service服务也是一些包装过的接口而已，针对Web Service服务的渗透测试和对常规API渗透测试是一样的、只是，可以使用安全工具来辅助进行，包括但不限于如下的工具：

• WebScarap
• SoapUI
• WCFStorm
• SOA Cleaner
• WSDigger
• wsScanner
• Wfuzz
• RESTClient
• BurpSuite
• WS-Attacker
• ZAP
• Metasploit
• WSDL Analyze

这里主要讲下如何使用BurpSuite和ReadAPI/SoapUI这两个工具来对Web Service服务进行渗透服务。

ReadyAPI+BurpSuite

网上的资料都是说的用SoapUI NG Pro+BurpSuite组合进行Web Service的渗透测试，但是现在SoapUI NG Pro试用版的下载已经更名为ReadyAPI了。

下载地址：https://smartbear.com/product/ready-api/api-functional-testing/free-trial/

整个过程如图：

image

其实就是SoapUI NG Pro作为Web Service的测试工具，Burp作为代理、监听SoapUI NG Pro用自己构造的payload报文打Web Service的流量报文，其中可以篡改对应的报文参数实现渗透测试。

这里本地以ReadyAPI为例。

先设置Burp代理，在File->Preferences->Proxy中设置Burp代理服务器地址：

image

然后新建安全测试任务，选择WSDL相关的API模块定义：

image

image

填写目标Web Service的WSDL地址，这里以前面编写的Demo为例：

image

点击Next，当WSDL解析完成后，会自动生成一系列的安全测试用例，默认都选上安全测试用例，点击Finish，然后运行测试用例：

image

扫描完成之后会给出扫描总结报告、还提供PDF版详细报告供查阅：

image

此时Burp中已经监听到了大量ReadAPI安全测试用例的报文，只需要将对应的报文放到Repeater中修改参数值继续进行渗透测试或者发到Intruder中进行Fuzzing即可：

image

后面就是针对常见API接口安全的渗透测试了，套路都是一样的。

SoapUI+BurpSuite

当使用没有安全测试用例扫描功能的SoapUI时，也可以用来生成对应格式的报文给Burp进行手工渗透测试。

这里以SoapUI Pro为例，前面的设置操作都是和ReadyAPI一样，只是没有了安全测试用例扫描功能而已。

设置好Burp代理，新建SOAP项目，填入WSDL地址完成解析后会显示如下图左边所有的Web Service服务和方法，其中可以单个填入参数值发送对应的请求报文并获取结果回显到界面中：

image

这里Burp监听到该报文，只需要修改参数值，而无须构造XML格式：

image

后面就是针对常见API接口安全的渗透测试了，套路都是一样的。

BurpSuite插件之Wslder

Wslder是BurpSuite，其在Extender的BApp Store中可以直接下载安装。虽然比前面的方法简便，但是有时候生成的请求会存在问题导致无法成功发包，此时就需要用到前面的方法了。

安装成功后，在Requests中右键选中Parse WSDL就能直接用了：

image

解析WSDL完成之后，在Wsdler栏可以看到解析出来对应的Web Service服务和方法以及对应的请求参数样例等，直接修改对应的参数值即可进行渗透测试：

image

五、 Web Service漏洞案例

SOAP型Web Service漏洞和Web漏洞并没有区别，只是请求的payload构造需要满足一些格式要求而已，具体还是要看Web Service服务端代码是怎么写的。比如命令注入、SQL注入、XSS、XXE、XPath注入、DoS、逻辑漏洞、信息泄露…等等。

这里以DVWS靶场为例演示几个SOAP类型Web Service请求的漏洞利用。

私信回复“资料”零取

1.200多本网络安全系列电子书

2.网络安全标准题库资料

3.项目源码

4.网络安全基础入门、Linux、web安全、攻防方面的教学视频

5.网络安全学习路线大纲结构图

XSS

换SOAP请求攻击时，注意点就是在SOAP中XSS payload的尖括号要进行HTML编码，不然会造成SOAP标签解析错误从而报错：

image

image

此外，一般Web Service服务站点也是支持上传XML文件的，这里就可以使用xhtml来触发XML XSS：

image

image

image

XXE

回显型XXE，注意exp的XML内容要写在SOAP的前面才能正常解析利用：

image

image

任意用户枚举

就是常规的API逻辑漏洞而已，利用响应结果二元组来推断：

image

image

express-fileupload原型链污染攻击

有意思的是，这里有个express-fileupload < 1.1.10版本的原型链污染漏洞，可导致DoS（某些情况下可导致任意代码执行）：

image

image

image

DoS

Web Service服务的交互很多都是用的XML格式数据。请求中的XML数据会由服务端的XML解析器进行解析和处理。

目前主要有两类XML解析器：

• 基于SAX（Simple API for XML）的XML解析器：内存中最多容纳2个元素。在这种情况下，基于SAX的解析器不会存在DoS问题；
• 基于DOM（Document Object Model）的XML解析器：会一次性读取客户端存储的所有XML数据，因此会导致内存中存在庞大的对象数据从而导致存在DoS问题。漏洞根源在于没有检查XML中节点的大小和数量；

针对元素名称的DoS攻击的示例：

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> 
<soapenv:Header/>
<soapenv:Body>
<TEST>
<BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA………BGABGABGABGABGABGABGABGABGABGA>
</TEST>
</soapenv:Body>
</soapenv:Envelope>

针对元素属性的DoS攻击的示例：

<soapenv:Envelope xmlns:soapenv=" 
<soapenv:Header/>
<soapenv:Body>
<TEST>
<BGA attribute=”BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA………BGABGABGABGABGABGABGABGABGABGA”></BGA>
</TEST>
</soapenv:Body>
</soapenv:Envelope>

针对元素个数的DoS攻击的示例（也可以通过重复某个特定元素达到同样效果）：

<soapenv:Envelope xmlns:soapenv=" 
<soapenv:Header/>
<soapenv:Body>
<TEST>
<BGA attribute1=”BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...BGABGABGABGABGABGABGABGABGABGA” attribute2=”BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...BGABGABGABGABGABGABGABGABGABGA” attribute3=”BGABGABGABGABGABGABGABGABGABGABGABGABGABGABGABGA...BGABGABGABGABGABGABGABGABGABGA”></BGA>
</TEST>
</soapenv:Body>
</soapenv:Envelope>

当然，存在XXE时，就可以进行XXE DoS攻击：

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE bga [
<!ELEMENT ANY ><!ENTITY bga1 "bga1">
<!ENTITY bga2 "&bga1;&bga1;&bga1;&bga1;&bga1;&bga1;">
<!ENTITY bga3 "&bga2;&bga2;&bga2;&bga2;&bga2;&bga2;">
<!ENTITY bga4 "&bga3;&bga3;&bga3;&bga3;&bga3;&bga3;">
<!ENTITY bga5 "&bga4;&bga4;&bga4;&bga4;&bga4;&bga4;">
<!ENTITY bga6 "&bga5;&bga5;&bga5;&bga5;&bga5;&bga5;">
]>
<bga>&bga6;</bga>