12 Web Services

12.1.
Introduction
12.2. Web Services Implementations
12.3. The WSDL Language
12.4. Attacks
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 of software together

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

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.

EXAMPLE
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.

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 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

You can implement web services 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.

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

XML-RPC, created in 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’s see an example.

http://xmlrpc.scripting.com/spec.html

POST /xml_rpc/web_service.php HTTP/1.1
User-Agent: Zend_XmlRpc_Client
Request headers such as
Host: wp.site user agent, hosts,
Content-Type: text/xml
Content-length: 179 content type, etc.
…
<?xml version="1.0"?>
<methodCall>
Payload format, which is XML
<methodName>My.Method</methodName> and must contain <methodCall>
<params>
<param>
with the <methodName> sub-
<value>www.google.com</value> item.
</param>
</params> Other required items can be
</methodCall> found here.
http://xmlrpc.scripting.com/spec.html

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: an array of objects to pass as arguments
• id: request ID used to match the responses/requests
http://www.jsonrpc.org/

The following is 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.
http://json.org/

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’s see an example.

https://www.w3schools.com/xml/xml_soap.asp
https://www.w3.org/TR/wsdl/
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
xmlns:soap="http://www.w3.org/2003/05/soap-envelope" request (XML)
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>

As we already said, REST (Representational State Transfer) is not a
protocol, but rather a set of principle to build web services that
focus on system's resources.
REST web services generally use JSON or XML, but any other
message transport format (such as plain-text) is possible.
https://www.ibm.com/developerworks/library/ws-restful/

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)

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

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 endpoint software knows

what services are provided by the server application, their
location, and the structure of the messages needed to request a
service.

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.

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.
https://www.w3.org/TR/wsdl/
https://www.w3.org/TR/wsdl20-primer/#basics
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

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>
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.

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.

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>

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>

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>

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.

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.

The message sayHelloRequest is described as follows:
<wsdl:message name="sayHelloRequest">
<wsdl:part name="name" element="ns:sayHello"/>
</wsdl:message>

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>

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.
https://www.wireshark.org/

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

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.

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.

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.

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.

If you want to dig deeper into the WSDL language, here are some
useful references:
• Understanding WSDL
• Understanding Providing WSDL Documents
• Understanding Web Services Specifications: WSDL
https://msdn.microsoft.com/en-us/library/ms996486.aspx#understand_topic5 https://www.ibm.com/developerworks/webservices/tutorials/ws-understand-web-
https://docs.oracle.com/cd/E57990_01/pt853pbh2/eng/pt/tibr/concept_UnderstandingProvi services2/ws-understand-web-services2.html
dingWSDLDocuments-076201.html#topofpage
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.

In order to find the WSDL, an attacker 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.

Below are simple Google dorks you can 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

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:

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.
https://msdn.microsoft.com/en-us/library/cy2a3ybs(v=vs.100).aspx

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.
http://uddi.xml.org/

You can use online resources such as soapclient.com to search for
public web services.
http://www.soapclient.com/uddisearch.html
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.

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

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.

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.

So far we know we can use these three functions to interact with the
application; let’s 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.

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.

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

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

able to delete users from the database.

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>

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.

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

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.

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.

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.

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.

Let’s 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.

Host: soap.site
Connection: Keep-Alive
The remote application User-Agent: PHP-SOAP/5.4.39-0+deb7u2
Content-Type: text/xml; charset=utf-8
client can perform the 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>

The remote attacker can invoke the method
deleteAllStudents by sending an 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.

Host: soap.site
The server application will Connection: Keep-Alive
successfully run Content-Type: text/xml; charset=utf-8
SOAPAction: "deleteAllStudents"
deleteAllStudents Content-Length: 230
because it only considers
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-

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.

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’s see how things work.

Host: soap.site
If the web service uses the Connection: Keep-Alive
SOAP protocol, the Content-Type: text/xml; charset=utf-8
SOAPAction: "getStudentInfo"
injection payload must be Content-Length: 230
encapsulated within a
specific XML message <SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/enve
based on the WSDL lope/"><SOAP-ENV:Body><SOAP-
description. ENV:getStudentInfo><id>' OR 'a'='a
</id></SOAP-ENV:getStudentInfo></SOAP-

Our previous web service is vulnerable to this type of attack. Let’s 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.

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 and 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
https://www.owasp.org/index.php/XPATH_Injection
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
XML-RPC JSON-RPC
http://xmlrpc.scripting.com/spec.html http://json-rpc.org/
SOAP WSDL
https://www.w3schools.com/xml/xml_soap.
http://www.w3.org/TR/wsdl20-primer/
asp
RESTful WSDL 1.1 and WSDL 2.0

http://www.ibm.com/developerworks/library http://www.w3.org/TR/wsdl
/ws-restful/ http://www.w3.org/TR/wsdl20-primer/
Ws-attack.org Understanding WSDL

https://msdn.microsoft.com/en-
http://ws-attacks.org/index.php/Main_Page
us/library/ms996486.aspx#understand_topic5

Understanding Providing WSDL Understanding Web Services
Documents Specifications
https://docs.oracle.com/cd/E57990_01/pt853pb http://www.ibm.com/developerworks/webservic
h2/eng/pt/tibr/concept_UnderstandingProviding es/tutorials/ws-understand-web-services2/ws-
WSDLDocuments-076201.html#topofpage understand-web-services2.html
DISCO UDDI
https://msdn.microsoft.com/en-
http://uddi.xml.org/
us/library/vstudio/cy2a3ybs(v=vs.100).aspx
SOAPClient External Entity

https://www.owasp.org/index.php/XML_Exte
http://www.soapclient.com/uddisearch.html
rnal_Entity_(XXE)_Processing
X-Path Injection
https://www.owasp.org/index.php/XPATH_In
jection

SOAP Web Service

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

12 Web Services

Uploaded by

Copyright:

Available Formats

12 Web Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

12 Web Services

Uploaded by

Copyright:

Available Formats

12.1.

12.2. Web Services Implementations

12.3. The WSDL Language

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

The main purpose of using web services is to have an

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

• Integration between applications: application 'A' uses

• Separation within an application: front-end scripts that

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

For example, a client application developed in Java running on a

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Here is another example:

An application on a mobile device or a browser on a standalone pc

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Business processes and operations are closely related to web

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Let’s see an example.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

The message sent to invoke a method is a request with a single

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

This is a single object serialized using JSON. Note the

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Let’s see an example.

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Through the WSDL specifications, any endpoint software knows

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

• Concrete: adds information about how the web service

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

We will explain the main elements available in the description

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

The binding section also contains the operations.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Unlike the old portType, interface elements do not point to

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Remember that in v. 2.0 messages are specified in the type

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

To inspect the whole communication and messages sent to the

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

The following is the first

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Right after our