12.1.

Introduction

12.2. Web Services Implementations

12.3. The WSDL Language

12.4. Attacks

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
A web service is a server side program that provides
functionalities that can be invoked and used
programmatically.
The main purpose of using web services is to have an
interoperable architecture that is able to connect different
devices and different pieces software together

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

They are usually intended to facilitate:
• Integration between applications: application 'A' uses
features implemented in application 'B'
• Separation within an application: front-end scripts that
use web services functionalities to update the content

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Protocols used by web services are well-known by all the
heterogeneous applications on the Internet.
For example, a client application developed in Java running
on a Linux machine will be able to communicate with a server
application developed in .NET running on a Windows
machine.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Here is another example:
an application on a mobile device or a browser on a
standalone pc will be able to interact with a server without
having to worry about its implementation.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The primary goal of a web service is to expose/advertise its
services. You can think of a service as a server application
processing parameters and returning a result to each client
requesting it.
Business processes and operations are closely related to web
services. You can associate each service to a given business
process.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web services often depict the actual business services
provided by a company. For example, a web service of an
airline carrier could provide the following services:
• Searchflight
• Bookflight
• Cancelflight
• Getmyflight

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web services can be implemented in many different ways.
The most commonly used and popular ones are:
• XML-RPC: remote procedure call (RPC) protocol that uses
XML (usually over HTTP) to invoke functionalities.
• JSON-RPC: remote procedure call protocol that uses JSON
• SOAP: messaging protocol that uses XML and provides
more functionalities of XML-RPC
• RESTful: set or principles to build a web service.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the next slides we will briefly introduce them but, then we
will focus our attention and tests only on SOAP web services.
We see how SOAP web services are built, how we can
fingerprint them but also, find vulnerabilities and exploit
them.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

XML-RPC, created in the 1998, was the first web service
protocol. It works by sending HTTP requests that call a single
method implemented on the remote system.
As you can imagine, the body of the request is in XML, thus it
can be used to send complex record and list structures.
Let us see an example.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Request headers such as
POST /xml_rpc/web_service.php HTTP/1.1
User-Agent: Zend_XmlRpc_Client
user agent, hosts,
Host: wp.site content type, etc.
Content-Type: text/xml
Content-length: 179
…

<?xml version="1.0"?>
<methodCall>
<methodName>My.Method</methodName>
Payload format. It is XML and
<params> must contain <methodCall> with
<param>
<value>www.google.com</value> the <methodName> sub-item.
</param> Other required items can be
</params>
</methodCall> found here.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
JSON-RPC is very similar to XML-RPC however, it provides
more human-readable messages and takes less space to send
the same message XML-RPC sends.
The message sent to invoke a method is a request with a
single object serialized using JSON. It has three properties:
• method: name of the method to invoke
• params: array of objects to pass as arguments
• id: request ID used to match the responses/requests

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following in an example of a JSON-RPC request:

POST /json_rpc/web_service.php HTTP/1.1 Request headers

User-Agent: my_user_agent
Host: wp.site such as user agent,
Content-Type: application/json-rpc hosts, content type,
Content-length: 57
… etc.
{"method": "MyMethod", "params": ["www.google.com"], "id": 1}

This is a single object serialized using JSON. Note the

three properties: method, params and id.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

SOAP (Simple Object Access Protocol) is somehow the
successor of XML-RPC since it provides more functionalities
such as encryption, digital signature, and routing of SOAP
messages.
Note that SOAP web services may also provide a Web
Services Definition Language (WSDL) declaration that
specifies how they may be used.
Let us see an example.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

POST /soap_rpc/web_service.php HTTP/1.1
User-Agent: PHP-SOAP Request headers such as
Host: wp.site
Content-Type: text/soap+xml user agent, hosts, content
Content-length: 179 type, etc.
…

<?xml version="1.0"?> Body of the

<soap:Envelope request (XML)
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://ws.site/soap_ws/ws">
<m:MyMethod>
<m:Host>www.google.com</m:Host>
</m:MyMethod>
</soap:Body>
</soap:Envelope>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As we already said, REST (Representational State Transfer) is
not a protocol, but rather a set of principle to build web
services that focuses on system's resources.
REST web services generally use JSON or XML, but any other
message transport format (such as plain-text) is possible.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

RESTful APIs are generally based on HTTP verbs to determine
the action:
HTTP verb Action
GET Retrieve a resource on the server, list a collection of records
• http://ws.site/book (e.g. List all books available)
• http://ws.site/book/1 (e.g. View a specific book)
PUT Change the state of a resource, replace or create it if it does not exist
• http://ws.site/book/1 (e.g. Replace a book)
POST Create a new resource or record
• http://ws.site/book (e.g. Create a specific book)
DELETE Delete a resource or record
• http://ws.site/book/1 (e.g. Delete a book)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
A web service is characterized by:

One or more Each reflects a service provided by the server application

Methods
It defines:
• The structure of each message used to request a service
A Protocol • The structure of a message sent by the web service in
response
• The transport method used to transmit the messages

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

WSDL stands for Web Services Description Language. Web
services, such as SOAP, use the WSDL language to formally
describe the provided services (the methods). Through the
WSDL specifications, any end point software knows what
services are provided by the server application, their location,
and the structure of the messages needed to request a
service.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In technical terminology, WSDL is an XML-based interface
description language. The description contains different
objects depending on the WSDL version; the objects describe
the messages, the services, how they can be requested, how
they can be transported.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

At the time of writing, WSDL can be distinguished in two main
versions: 1.1 and 2.0.
Although 2.0 is the current version, many web services still
use WSDL 1.1 therefore, in the next slides we will see both
WSDL specifications.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

First of all, it is important to know that WSDL documents have
abstract and concrete definitions:
• Abstract: describes what the service does, such as the
operation provided, the input, the output and the fault
messages used by each operation;
• Concrete: adds information about how the web service
communicates and where the functionality is offered

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following image shows the main differences between
WSDL 1.1 and WSDL 2.0 definitions. We will inspect the
most important elements in future slides.
WSDL 1.1 <definition> <description> WSDL 2.0

<types>..</types>
<types>..</types>
Abstract <message>..</message>
description <interface>..</ interface>
<portType>..</ portType>

Concrete <binding>..</binding> <binding>..</binding>

description <service><port..</service> <service><endpoint...</service>
</definition> </description>
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
As you already know,
this file contains the
description of all the
provided services.
Before requesting a
service, the client
application will ask
for the WSDL file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the following sections, we will see a server application
offering a sayHello service. The service gets the name and
surname of the person requesting it then returns a custom
hello response.
We will explain the main elements available in the description
using WSDL 1.1 and 2.0, while we will see code examples for
the WSDL 1.1 only.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The binding element describes how to access the service. It
defines the message format and protocol details for
operations, messages (v. 1.1.) and interfaces (v. 2.0).
The binding section also contains the operations.
<wsdl:binding name="HelloServiceSoap11Binding"
type="ns:HelloServicePortType">
<soap:binding transport="http://schemas.xml
soap.org/soap/http" style="document"/>
< . . [WSDL OPERATIONS] . . />
</wsdl:binding>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The PortType (v. 1.1) element defines the web service, the
operations a client is allowed to request, the messages
passed to each operation and the returned messages.

<wsdl:portType name="HelloServicePortType">
<wsdl:operation name="sayHello">
<wsdl:input message="ns:sayHelloRequest"/>
<wsdl:output message="ns:sayHelloResponse“/>
</wsdl:operation>
</wsdl:portType>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The operation object defines the SOAP actions and the
encoding of each message, for example, "literal". An
operation can be thought of as a method in a traditional
programming language.
<wsdl:operation name="sayHello">
<soap:operation soapAction="sayHello" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Instead of portType, WSDL v. 2.0 uses interface elements
which define a set of operations, representing an interaction
between the client and the service. Each operation specifies
the types of messages that the service can send or receive.
Unlike the old portType, interface elements do not point
to messages anymore (it does not exist in v. 2.0), instead they
point to the schema elements contained within the types
element.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The Message object (available only in v. 1.1) contains the
messages required and returned by any operation. For
example, the operation named sayHello requires the
message sayHelloRequest and returns the message
sayHelloResponse.
Remember that in v. 2.0 messages are specified in the type
element.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The message sayHelloRequest is described as follows:

<wsdl:message name="sayHelloRequest">
<wsdl:part name="name" element="ns:sayHello"/>
</wsdl:message>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Where ns:sayHello represents a complex data type:

<xs:element name="sayHello">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="surname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In order to make things clearer, let us inspect all the
communications when interacting with a SOAP web service.
To inspect the whole communication and messages sent to
the web service, we are going to sniff the traffic with
Wireshark on both our host and server.
This allows us to inspect not only our Browser requests but
also, its responses.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The target web application simply allows us to request some
information on a databases of students. From the user
interface, lets request try to get information about the
student with ID 1.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

1) Browser -> Server Request

The following is the

first request issued by
our browser when we
click on Submit.
In the response we
have the page
showing the student
information.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
2) Get the WSDL file

Right after our

request, the next
thing we request is
the WSDL file on
the server. The
response contains
the WSDL file.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

3) Server request to the Web Service

Here, the server sends a

SOAP-POST request to
the Web Service. As you
can see, the body of the
request is XML and
contains the operation
getStudentInfo and the
parameter 1.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Now you should have a better idea of how a SOAP Web
Service works. During your career you will surely find slightly
different implementations but, the basic communications and
interactions are the ones we just saw in the previous slides.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If you want to dig deeper in the WSDL language here you find
some useful references:
• Understanding WSDL
• Understanding Providing WSDL Documents
• Understanding Web Services Specifications: WSDL

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
When dealing with web service security, accessing the WSDL
file is the first step. This gives us the full list of operations and
types allowed by the server as well as the correct syntax to
use, inputs, outputs and all the useful information we may
need to run successful attacks.
In the next slides we will see how attackers and penetration
tester may be able to enumerate WSDL files.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

An attacker, in order to find the WSDL, can leverage Google’s
capabilities. Only indexed resources are returned by Google
so our WSDL must have been indexed if you wish to use this
method.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

These are simple Google dorks to use to find a WSDL:
filetype:wsdl To filter by WSDL file type
site: <yourTarget> To filter by site
inurl:wsdl To filter all URLs with the string WSDL
To search all of the indexed WSDL files on the target
www.vuln.att, you would use the following search string:
site:www.vuln.att filetype:wsdl

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Once the SOAP service has been identified, another way to
discover WSDL files is by appending ?wsdl,.wsdl or ?disco
to the end of the service URL:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Note:

DISCO is a Microsoft .NET Web Services discovery tool used to

discover the URLs of XML Web services located on a Web
Server.
The .disco documents are XML files that, similarly to WSDL,
describe the Web service.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

UDDI (Universal Description, Discovery and Integration) is a
directory service used for storing information about web
services. Thanks to UDDI, anyone can search for information
about Web Services that are made available by or on behalf
of a business.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You can use online resources such as soapclient.com,
xmethod.net or service-repository.com to search for public
web services.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Once we find WSDL files we can start inspecting them and
gather valuable information about the web service. As you
already know, this allows us to gather information such as
operations, data, syntax and much more.
In the next attack, we will assume the attacker already has
access to the WSDL file of the target web service.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attack consists of the following few steps:
1. The attacker starts the client application and gets the
WSDL file
2. The attacker analyzes the WSDL file to look for hidden
methods and to get general information about the
structure of each operation
3. The attacker invokes some (hidden) methods

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For this attack we will use a simple server application using
web services. The server application is a web application used
by a university department to perform simple operations on
information about its students.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Through the web application, the user can request only three
operations: Student Info, Student Exams, and Student
Billing. These three operations require the parameter
studentID.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

So far we know we can use these three functions to interact
with the application but, let us request the WSDL file and see
what we can find. Remember that once we identify a web
service, most of the time, we can request the WSDL file by
adding ?wsdl at the end of the URL.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

By inspecting the WSDL file we can see a new operation:
deleteStudent.
This operation is apparently not shown as one of the available
features through the web interface however, it is available in
the web service description file. This new method either
might be or, might not be runnable by an unauthenticated
user.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The following is the WSDL
file just obtained and all
the functions available. As
we can see there are the
three function listed in the
web application menu,
plus the deleteStudent
operation.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker can no try to invoke the deleteStudent method
and attempt to delete a user. If no further checks are in place,
chances are that the attacker will be able to delete users from
the database.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

With the following request, an attacker may be able to call
the deleteStudent operation and force the Web service to
delete the student with id 8.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:deleteStudent>
<id>8</id>
</SOAP-ENV:deleteStudent>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Each SOAP client interacting with a web service must specify
the requested operation and related parameters via SOAP
messages. For example, the following SOAP message could be
used by a SOAP client to ask for the removal of the user with
the ID James.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As you can see in
the header fields,
SOAPAction is set
to deleteStudent.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The SOAP standard permits one to specify a SOAPAction
header. This is a specific header containing the operation’s
name. Its goal is to inform the web service what operation is
contained in the SOAP Body without needing XML parsing.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 POST /StudentsWS.php HTTP/1.1
Host: soap.site
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.4.39-0+deb7u2
Content-Type: text/xml; charset=utf-8
SOAPAction: "deleteAllStudents"

This could be a good optimization but, some web service

implementations only use this header to determine the
operation. In other words, they ignore the SOAP body.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

It could also resemble a security issue if the firewall only
processes the SOAP body. For example, a firewall could allow
a request with a correct SOAP body but, not a malicious
SOAPAction header.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In order to mount this attack, the following is necessary:
• The attacker has access to the WSDL file, and knows all the
services (methods) offered by the server application.
• The attacker knows and can reach the end-point of the web
service.
• Some web service methods are protected by a firewall and
cannot be invoked.
• The firewall filters the requests only by SOAP body.
• The server application relies on the SOAPAction header to
detect the operation type.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Let us consider the following scenario:
• The attacker has access to the WSDL file and knows two
interesting operations: getUserInfo and deleteAllStudents
• A firewall filters out requests coming from remote clients
invoking the operation deleteAllStudents. Local client
requests are allowed.
• The firewall uses only the SOAP body to filter requests.
• The server application relies on the SOAPAction header to
detect the operation type.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 POST /StudentsWS.php HTTP/1.1
Host: soap.site
The remote application Connection: Keep-Alive
User-Agent: PHP-SOAP/5.4.39-0+deb7u2
client can perform the Content-Type: text/xml; charset=utf-8
SOAPAction: "getStudentInfo"
following request because Content-Length: 230
the getStudentInfo <?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-
operation has not been ENV="http://schemas.xmlsoap.org/soap/en
firewalled. velope/"><SOAP-ENV:Body><SOAP-
ENV:getStudentInfo><id>1</id></SOAP-
ENV:getStudentInfo></SOAP-
ENV:Body></SOAP-ENV:Envelope>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The remote attacker can invoke the method
deleteAllStudents by sending a HTTP request with the
SOAPAction header set to deleteAllStudents and the
SOAP body set as the previous request. The firewall will not
filter the request because the SOAP body is allowed.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 POST /StudentsWS.php HTTP/1.1
The server application Host: soap.site
Connection: Keep-Alive
will successfully run User-Agent: PHP-SOAP/5.4.39-0+deb7u2
Content-Type: text/xml; charset=utf-8
deleteAllStudents SOAPAction: "deleteAllStudents"
Content-Length: 230
because it only considers
<?xml version="1.0" encoding="UTF-8"?>
the SOAPAction header <SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/en
to determine the invoked velope/"><SOAP-ENV:Body><SOAP-
operation. ENV:getStudentInfo><id>1</id></SOAP-
ENV:getStudentInfo></SOAP-
ENV:Body></SOAP-ENV:Envelope>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This attack can be avoided in one of the following ways:
• By disabling the SOAPAction header.
• By configuring the firewall to inspect the SOAPAction
header when filtering the coming requests.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Any server application using a DBMS can be vulnerable to SQL
injection. Obviously, the issue occurs when user input is not
properly sanitized.
The traditional theories on SQL injection are always valid, but
in this case, the injection payload must be encapsulated in
XML messages before being sent. Most of the time, the client
application will take care of this however, in case you are
issuing raw requests to the web services, let us see how
things work.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 POST /StudentsWS.php HTTP/1.1
Host: soap.site
If the web service uses Connection: Keep-Alive
the SOAP protocol, the User-Agent: PHP-SOAP/5.4.39-0+deb7u2
Content-Type: text/xml; charset=utf-8
injection payload must SOAPAction: "getStudentInfo"
Content-Length: 230
be encapsulated within a
<?xml version="1.0" encoding="UTF-8"?>
specific XML message, <SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/e
based on the WSDL nvelope/"><SOAP-ENV:Body><SOAP-
ENV:getStudentInfo><id>' OR 'a'='a
description. </id></SOAP-ENV:getStudentInfo></SOAP-
ENV:Body></SOAP-ENV:Envelope>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Our previous web service is vulnerable to this type of attack.
Let us see what happens when we use the previous payload
against the getStudentInfo function.

All students are listed in

the results. So the
parameter is vulnerable
to SQL injection.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This type of attack is an input validation attack. Moreover, it is
important to know that since these types of Web Services use
XML files, they may also be vulnerable to XPath Injection,
External Entity attacks and all the XML related vulnerabilities.
To avoid them, you should filter or sanitize user input. You
can obtain this in the following ways:
• By using parameterized SQL queries
• By using stored procedures
• By validating the user input directly
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
XML-RPC JSON-RPC

SOAP WSDL

RESTful WSDL 1.1 and WSDL 2.0

Ws-attack.org Understanding WSDL

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

UnderstandingProviding Understanding Web
WSDL Documents Services Specifications

DISCO UDDI

SOAPClient XMethod

X-Path Injection External Entity

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

SOAP Web Service

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 Web Services
In these Web Services labs, the student
can practice attack techniques against
SOAP web services, find and inspect
WSDL files and much more

Powered by TCPDF (www.tcpdf.org)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015