scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

Penetration Testing Tool for Web Services Security

24 Jun 2012-pp 163-170
TL;DR: An overview of the design decisions and evaluation of four Web Services frameworks and their resistance against WS-Addressing spoofing and SOAPAction spoofing attacks is given.
Abstract: XML-based SOAP Web Services are a widely used technology, which allows the users to execute remote operations and transport arbitrary data. It is currently adapted in Service Oriented Architectures, cloud interfaces, management of federated identities, eGovernment, or millitary services. The wide adoption of this technology has resulted in an emergence of numerous -- mostly complex -- extension specifications. Naturally, this has been followed by a rise in large number of Web Services attacks. They range from specific Denial of Service attacks to attacks breaking interfaces of cloud providers or confidentiality of encrypted messages. By implementing common web applications, the developers evaluate the security of their systems by applying different penetration testing tools. However, in comparison to the well-known attacks as SQL injection or Cross Site Scripting, there exist no penetration testing tools for Web Services specific attacks. This was the motivation for developing the first automated penetration testing tool for Web Services called WS-Attacker. In this paper we give an overview of our design decisions and provide evaluation of four Web Services frameworks and their resistance against WS-Addressing spoofing and SOAPAction spoofing attacks. %WS-Attacker was built with respect to its future extensions with further attacks in order to provide an all-in-one security checking interface.

Summary (4 min read)

Introduction

  • A short overview of some well-known Web Service specific attacks mainly taken from [11] can be seen in Table I.
  • The adversaries could e.g. apply the HashDoS attack on the XML-structure1 or force the server to execute expensive cryptographic algorithms.
  • Basic design and implementation decisions are summarized in Sections IV and V.

II. FOUNDATIONS

  • This section introduces the fundamentals of XML and Web Services relevant aspects for further description of the penetration testing framework.
  • Due to their flexibility, the XML documents gained in recent years much popularity.
  • They are currently used for data transmission, data storage, or in case of a Web Service for function invocation calls.
  • Since XML documents often contain confidential and reliable data, the W3C consortium has developed standards that describe the XML syntax for applying cryptographic primitives to arbitrary XML data.
  • In parallel, XML Signature guarantees data integrity and authenticity.

B. SOAP-based Web Services

  • SOAP is a standard which describes message exchange with a Web Service [4].
  • SOAP messages basically consist of an Envelope element with two child elements named Header and Body:.
  • The concrete structure of the SOAP message used to communicate with a Web Service and the binding information is described in the Web Service Description Language (WSDL) [5].
  • SOAP does not specify any concrete transport protocol.
  • This allows to define additional data in the HTTP headers and filter the messages using standard HTTP firewalls.

C. Web Services Addressing

  • Web Services Addressing (WS-Addressing) [18] is a standard supporting the message routing definition directly inside of the exchanged SOAP messages.
  • This makes the routing data independent of the underlying protocol and of any transport characteristics.
  • Using this message the client accesses the shops’ services defined in the wsa:To element.
  • He executes the function buy article in the wsa:Action element.
  • Otherwise, the message is forwarded to a service defined in the wsa:FaultTo element, which handles reordering and informs the client about the next processing steps.

D. Web Services Security

  • SOAP-based Web Services are commonly exchanged over HTTP.
  • This allows to use SSL/TLS [19] as a secure transport mechanism.
  • This mechanism however does not bring advantages if the SOAP messages are transfered over more than one endpoints.
  • Therefore, the OASIS group has maintained the Web Service Security (WS-Security) [7], which specifies how to: 1) Sign and verify (parts of) SOAP messages using XML Signature.
  • 2) Encrypt and decrypt (parts of) SOAP messages using XML Encryption.

A. Web Service Specific vs. Non-Specific Attacks

  • Web Services use XML-based messages sent over different protocols.
  • Specific Web Service attacks exploit vulnerabilities on SOAP and XML.
  • Information about them can be found on the OWASP web site3.
  • A good all-in-one tool for testing web applications is the Web Application Attack and Audit Framework (w3af)4.
  • The only possibility to attack Web Services is to do manual tests, e.g. using soapUI5.

C. WS-Addressing Spoofing

  • WS-Addressing spoofing is a further Web Service specific attack [11].
  • The idea of this attack is depicted in Figure 2: The attacker sends a SOAP request to the server containing a WS-Addressing header, which provokes the server to send the SOAP response to a different endpoint.
  • The specification has three different methods for doing this: ReplyTo:.
  • The server sends the response to any different endpoint.
  • 6Hacking D-Link Routers With HNAP: http://www.sourcesec.com/Lab/ dlink hnap captcha.pdf.

A. Requirements for Plugin Developers

  • The requirements for plugin developers can be summarized to the following aspects:.
  • 2) Any attack category must be supported (spoofing attacks, Denial of Service, etc.) 3) Open for extension: there must be support even for prospective, not yet invented, attacks.
  • In general, a plugin author has the task to create the attackplugin without knowing WS-Attacker’s internals.
  • This is why WS-Attacker will only provide a plugin interface and some helper classes – each attack request must be sent by the plugin itself.

B. Requirements for Framework Users

  • The requirements for framework users must be seen from a different point of view.
  • 3) The users do not need any knowledge about XML or Web Services and especially, they do not need any knowledge about XML Security.
  • A typical WS-Attacker user might be a company, which provides a Web Service either for their clients, or for its internal processes.
  • This service should be secure against all known attacks.
  • By using WS-Attacker, the company can easily check for vulnerabilities.

C. Processing Steps

  • For setting up the configuration to attack a Web Service, the framework will work as follows: 1) The user has to load a WSDL.
  • 2) The framework has to analyze it and extract all possible operations.
  • The response to this request represents the normal state of the Web Service.
  • Each plugin represents exactly one attack and the framework uses a plugin manager to hold and activate these plugins.
  • After the attack plugins finish, the framework will present the results.

D. Framework Results

  • WS-Attacker distinguishes between three types of results: 1) It displays whether the attack was successful or not.
  • 3) It produces a kind of log entries that can be filtered by their importance level and may contain additional infos, e.g. concrete SOAP messages.
  • The second one rates the potential risk of an attack.
  • The last results can be seen as an advanced log: Each plugin can produce a Log Entry which belongs to a display level.
  • The user can then change this level to filter in and out those entries to view only the ones he is interested in.

A. Overview

  • The program is divided into two parts: Framework:.
  • Its task is to set up the environment for attacking Web Services and manage the processing steps described in Section IV-C. Plugin Architecture: WS-Attacker can hold any number of plugins, where each plugin represents an attack.

C. Program Structure

  • Mainly, there are two parts: The Plugin Architecture and the Operation Architecture.
  • The Operation Architecture represents everything that has to do with creating Web Service requests and can be seen as the main part of the framework.
  • This is the place for the attack plugins.
  • Each plugin extends the AbstractPlugin class and can have one or more AbstractOptions, for example a signature file or some other configuration parameters.
  • The user can choose whether he wants to see only the most important results, e.g. which parts of the attack was successful, or even SOAP request and response contents.

D. Attack Plugin Interface

  • In general, an attack plugin has the following tasks: 1) Running the attack using the given operation, request and plugin options.
  • The user will see those results in real-time and can filter them according to their level.
  • Furthermore, each plugin needs to rate the attack success.
  • It returns a container containing Objects which extend an AbstractOption interface.
  • Inside this method, the author should generate the results and depend if an attack was successful using the success interface.

F. Minimal Implementation

  • This section gives a minimal implementation example for a SOAPAction spoofing attack plugin.
  • In general, there are four steps to take: 1) Implementing the attack identity methods like getName and getDescription.
  • 2) The server ignores the SOAPAction Header and executes the first child of the SOAP Body.
  • The list above will be used for the integer success interface, so that a framework user can see what was successful and how dangerous it was.
  • Search for the first body child in the response.

VI. EVALUATION

  • The authors tested feasibility of WS-Attacker using four widely deployed Web Services frameworks: Apache Axis2 v1.6.17, JBossWS Native 6.0, JBossWS CXF 7.08, and .NET Web Services 3.09.
  • JBossWS native and JBossWS CXF do it vice versa:.
  • An exemplary attack result presenting the vulnerable Apache Axis2 framework is depicted in Figure 5.
  • Later evaluation showed that this framework is vulnerable to SOAPAction spoofing even if XML Signature is applied.
  • Thus, the adversary could execute arbitrary function on a secured server being in possession of a single validly signed document.

VII. CONCLUSION

  • In this paper the authors presented the penetration testing tool for Web Services called WS-Attacker.
  • The results proved feasibility of their approach.
  • The authors mention e.g. Denial of Service and XML Signature Wrapping attacks, or attacks on XML Encryption.
  • Additionally, an extension of their framework can be seen in the direction of Single Sign-On, which is typically realized using the XML-based SAML specification.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Penetration Testing Tool for Web Services Security
Christian Mainka, Juraj Somorovsky, J
¨
org Schwenk,
Horst G
¨
ortz Institute for IT Security
Ruhr University Bochum, Germany
{Christian.Mainka, Juraj.Somorovsky, Joerg.Schwenk}@rub.de
Abstract—XML-based SOAP Web Services are a widely used
technology, which allows the users to execute remote opera-
tions and transport arbitrary data. It is currently adapted in
Service Oriented Architectures, cloud interfaces, management
of federated identities, eGovernment, or millitary services. The
wide adoption of this technology has resulted in an emergence of
numerous mostly complex extension specifications. Naturally,
this has been followed by a rise in large number of Web Services
attacks. They range from specific Denial of Service attacks
to attacks breaking interfaces of cloud providers [1], [2] or
confidentiality of encrypted messages [3].
By implementing common web applications, the developers
evaluate the security of their systems by applying different
penetration testing tools. However, in comparison to the well-
known attacks as SQL injection or Cross Site Scripting, there
exist no penetration testing tools for Web Services specific attacks.
This was the motivation for developing the first automated
penetration testing tool for Web Services called WS-Attacker.
In this paper we give an overview of our design decisions
and provide evaluation of four Web Services frameworks and
their resistance against WS-Addressing spoofing and SOAPAction
spoofing attacks.
Index Terms—SOAP-based Web services, WS-Security, WS-
Addressing spoofing, SOAPAction spoofing, Penetration Testing
Tool
I. INTRODUCTION
Service-oriented architectures (SOAs) have been developed
as a new software paradigm, which enforces software modular-
ization and reuse. The key technology to implement SOA has
become the eXtensible Markup Language (XML), surrounded
with the related W3C-standards such as SOAP [4], WSDL [5],
or XML Schema [6]. It has been relatively quickly realized
that these architectures need to support flexible security mech-
anisms. Thus, the OASIS consortium has developed additional
standards describing application of security mechanisms in
SOAP messages (WS-Security [7]), building security poli-
cies (WS-Security Policy [8]), or exchanging authentication
(SAML [9]) and authorization tokens (XACML [10]).
Unfortunately, the complexity and a large number of these
standards have led to emergence of Web Services specific
attacks. A short overview of some well-known Web Service
specific attacks mainly taken from [11] can be seen in Table I.
The most important attacks are those breaking cryptographic
primitives defined in the XML messages. The so called XML
Signature Wrapping attacks described by McIntosh and Austel
in 2005 [12] allow an attacker to arbitrarly modify signed mes-
sages. The practical impact of these attacks has been shown by
its application on Amazon EC2 SOAP and Eucalyptus cloud
Web Service interfaces [1], [2] or on different SAML-based
XML Signature Wrapping Attack on XML Encryption
Oversize Payload Coercive Parsing
SOAPAction spoofing XML Injection
WSDL Scanning Metadata spoofing
Attack Obfuscation Oversized Cryptography
BPEL State Deviation Instantiation Flooding
Indirect Flooding WS-Addressing spoofing
Middleware Hijacking
TABLE I
OVERVIEW OF EXISTING WEB SERVICE SPECIFIC ATTACKS.
Single Sign-On frameworks [13]. Another relevant attack in
this area has been presented at CCS’11 [3]. It has been shown
that it is possible to decrypt arbitrary XML ciphertexts if a
server working as a plaintext validity oracle is given. The
development of countermeasures against this attack is not
trivial as many side-channels can be revealed by the server-
side implementation [14]. In addition to the attacks on cryp-
tographic data primitives, there exists a whole series of highly
efficient Denial of Service (DoS) attacks. The adversaries
could e.g. apply the HashDoS attack on the XML-structure
1
or
force the server to execute expensive cryptographic algorithms.
The developers are usually familiar only with a small
number of the Web Services standards and therefore, they are
not able to identify vulnerabilities in the implemented Web
Services interfaces. Compared to attacks like SQL injection
and Cross Site Scripting (XSS) which can be checked with
a number of penetration testing tools there are no solutions
offering automated testing of XML-specific vulnerabilities. For
these reasons it was decided to develop the first automated
penetration testing tool for XML-based Web Services called
WS-Attacker. In this paper, the basic design decisions for creat-
ing this modularized tool are presented and a description of the
implementation and inclusion of new attacks considering the
interfaces of WS-Attacker is given. Afterwards, details of two
attack implementations already included in the framework are
deepened: WS-Addressing spoofing and SOAPAction spoof-
ing. The evaluation of their implementation is presented using
four widely used Web Services frameworks: Apache Axis2,
JBossWS native, JBossWS CXF and .NET Web Services. WS-
Attacker is offered as an open-source implementation
2
to a
wide range of Web Services developers.
The rest of the paper is organized according to the structure
1
https://bugzilla.redhat.com/show
bug.cgi?id=CVE-2012-0841
2
http://sourceforge.net/projects/ws-attacker

delineated below: Section II gives an overview of paper
relevant technologies. Section III briefly describes the WS-
Addressing spoofing and SOAPAction spoofing attacks. Ba-
sic design and implementation decisions are summarized in
Sections IV and V. The evaluation results are included in
Section VI and the conclusion in Section VII.
II. FOUNDATIONS
This section introduces the fundamentals of XML and
Web Services relevant aspects for further description of the
penetration testing framework.
A. XML Security
The eXtensible Markup Language (XML) [15] is a specifi-
cation offering a possibility for flexible storage of tree-based
data. Due to their flexibility, the XML documents gained in
recent years much popularity. They are currently used for data
transmission, data storage, or in case of a Web Service for
function invocation calls.
Since XML documents often contain confidential and re-
liable data, the W3C consortium has developed standards
that describe the XML syntax for applying cryptographic
primitives to arbitrary XML data. The resulting standards have
become XML Encryption [16] and XML Signature [17]. Using
XML Encryption to XML data ensures its confidentiality.
In parallel, XML Signature guarantees data integrity and
authenticity. Both can be applied to arbitrary data in the
document.
B. SOAP-based Web Services
SOAP is a standard which describes message exchange with
a Web Service [4]. SOAP messages basically consist of an
Envelope element with two child elements named Header
and Body: The SOAP header can contain meta information
such as nonces, timestamps, or XML Signatures. The SOAP
body is used for storing a Web Service operation and its
parameters. The concrete structure of the SOAP message used
to communicate with a Web Service and the binding infor-
mation is described in the Web Service Description Language
(WSDL) [5].
SOAP does not specify any concrete transport protocol. In
most cases HTTP is used. This allows to define additional data
in the HTTP headers and filter the messages using standard
HTTP firewalls. One example of an additional HTTP header
is the SOAPAction field, which redundantly corresponds the
SOAP body operation. According to the SOAPAction field,
the firewall can decide e.g. if the message sender can execute
the given operation.
An example of a SOAP message including HTTP parame-
ters is given in Listing 1.
POST / w e bs e r v i c e HTTP / 1 . 1
SOAP Ac tion: addUser
<s o a p e n v: E n v e l o p e>
<s o ap e n v :H e a d er />
<so ap en v: Bo dy>
<ad d U s e r>
<name>Bob< / name>
< / a d d U s e r>
< / s o ap en v: Bo dy>
< / s o a p e n v : En v e l o p e>
Listing 1. SOAP message transfered over HTTP with an additional
SOAPAction parameter.
C. Web Services Addressing
Web Services Addressing (WS-Addressing) [18] is a stan-
dard supporting the message routing definition directly inside
of the exchanged SOAP messages. This makes the routing data
independent of the underlying protocol and of any transport
characteristics.
An example of WS-Addressing defined in the SOAP mes-
sage header gives Listing 2. Using this message the client
accesses the shops’ services defined in the wsa:To element. He
executes the function buy article in the wsa:Action element.
If the article is in the store, the message can be forwarded to
the billing service in the wsa:ReplyTo property. Otherwise, the
message is forwarded to a service defined in the wsa:FaultTo
element, which handles reordering and informs the client about
the next processing steps.
<s o ap e n v :H e a d er x ml ns : ws a = . . . / a d d r e s s i n g >
<wsa: To> s e r v i c e s / s h op< / w sa: To>
<w s a : A c t i o n> b u y a r t i c l e</ w s a : A ct i o n>
<w s a : R e p l yTo>
<ws a :A d d re s s> s e r v i c e s / b i l l i n g</ w sa : A d d r es s>
< / w s a :ReplyTo>
<w s a : F a ul t T o>
<ws a :A d d re s s> s e r v i c e s / o u t o f s t o c k< / y
w s a : A d dr e s s>
< / w s a : F a u l tT o>
< / s o a p en v : H e a d e r>
Listing 2. WS-Addressing applied in the SOAP header
D. Web Services Security
SOAP-based Web Services are commonly exchanged over
HTTP. This allows to use SSL/TLS [19] as a secure transport
mechanism. This mechanism however does not bring advan-
tages if the SOAP messages are transfered over more than
one endpoints. Therefore, the OASIS group has maintained
the Web Service Security (WS-Security) [7], which specifies
how to:
1) Sign and verify (parts of) SOAP messages using XML
Signature.
2) Encrypt and decrypt (parts of) SOAP messages using
XML Encryption.
3) Add security tokens (like timestamps, credentials) to
SOAP messages.
This allows to secure the messages on the message-level
and protect them during the whole transport even over a large
number of endpoints.
III. WEB SERVICES ATTACKS
The following section gives an overview of existing attack
classes used against Web Services relevant for this paper.

A. Web Service Specific vs. Non-Specific Attacks
Web Services use XML-based messages sent over different
protocols. They can execute operations on a remote system
or access a database. The XML-based SOAP messages can
contain different data giving the client access rights to a service
operation or addressing a next Web Service, which should be
invoked. Considering these facts, a Web service interface can
be vulnerable to the following groups of attacks:
Non-specific Web Service attacks are abusing weaknesses
in the back-end of an application, e.g. Buffer Overflows
or SQL Injection.
Specific Web Service attacks exploit vulnerabilities on
SOAP and XML. They attack the XML-parser with De-
nial of Service attacks, build unexpected SOAP messages,
or attack the confidential data transmitted in the SOAP
message.
The preferred way to build secure Web Services is checking
for security by means of an attack framework. If the service
resists these attacks, it is a good indicator for security. Non-
specific Web Service attacks are well-known from web appli-
cations. Information about them can be found on the OWASP
web site
3
. A good all-in-one tool for testing web applications
is the Web Application Attack and Audit Framework (w3af)
4
.
Currently, there is nevertheless no automated vulnerability
scanner which uses web service specific attacks. The only
possibility to attack Web Services is to do manual tests, e.g.
using soapUI
5
.
B. SOAPAction Spoofing
SOAPAction spoofing is a Web Service specific attack [11],
which misuses the SOAPAction parameter in the HTTP header.
The basic idea of the attack can be explained using the follow-
ing example. Consider a Web Service with two operations: Op-
erationA and OperationB. The WSDL for this service defines
the SOAPAction for each operation in the operation element.
Let ActionA and ActionB be the corresponding actions. A valid
SOAP message for OperationA contains the corresponding
names in both fields: the SOAPAction parameter is set to
ActionA and the name of the first SOAP body element is
OperationA.
A SOAPAction spoofing attack changes the SOAPAction
header to a different action as shown in Listing 3.
POST / w e b s e r v i c e HTTP / 1 . 1
H o s t : s oa p A c t i o n S p o o fi n g H o s t
SOAP Ac tion: ActionB
<s o a p e n v: E n v e l o p e>
<s o ap e n v :H e a d er />
<so ap en v: Bo dy>
<OperationA />
< / s o ap en v: Bo dy>
< / s o a p e n v : En v e l o p e>
Listing 3. SOAPAction spoofing attack message
3
http://owasp.org
4
http://w3af.sourceforge.net/
5
http://www.soapui.org/
HTTP-Header:
ActionB
SOAP Body:
OperationA
HTTP-Firewall
Allow: B
Deny: A
Web Service
Fig. 1. Attacking a Web Service with SOAPAction spoofing.
In some cases, this message can provoke an unwanted
reaction. Consider an HTTP Firewall, which handles incoming
requests and a Web Service with two operations. If the firewall
only checks the SOAPAction header, the message in Listing 3
is illegally allowed and will be forwarded to the Web Service,
see Figure 1. The Web Service logic executes the SOAP
body operation, because it does not check authentication
it believes, that the firewall performs this task.
If OperationB is a public operation like getServerTime and
OperationA one, that needs authentication, e.g. deleteAllUsers,
the SOAPAction spoofing attack can be used to execute
deleteAllUsers without any authentication. A real life example
for this attack was published in January 2010
6
: SourceSec
Security Research has found a vulnerability in D-Link routers,
which allowed administrative access using SOAPAction spoof-
ing.
C. WS-Addressing Spoofing
WS-Addressing spoofing is a further Web Service specific
attack [11]. The idea of this attack is depicted in Figure 2:
The attacker sends a SOAP request to the server containing a
WS-Addressing header, which provokes the server to send the
SOAP response to a different endpoint.
The specification has three different methods for doing this:
ReplyTo: The server sends the response to any different
endpoint. This will only work if the request was valid
and no error occurs.
FaultTo: The server sends any SOAP Fault to a different
endpoint. For attacking a Web Service, a SOAP Body
without any children can be used, as this will always
return a SOAP Fault. Thus, the impact by this method is
more powerful, as provoking SOAP Faults is much easier
as a valid request.
To: The server uses a different endpoint for everything,
including valid responses and SOAP Faults.
Using WS-Addressing for asynchronous message exchange
raises different attack possibilities, e.g. flooding another Web
Service, or even Distributed Denial of Service is possible.
Thereby, only one of the three methods mentioned above is
sufficient. A countermeasure against WS-Addressing spoofing
is the verification of the endpoint reference (Whitelist), ideally
before any computation.
6
Hacking D-Link Routers With HNAP: http://www.sourcesec.com/Lab/
dlink
hnap captcha.pdf

SOAP Envelope
SOAP Header
WS Addressing
http://serverB
SOAP Body
Server A
initial
Web Service
Server B
another
Web Service
WS Addressing
http://serverB
Fig. 2. Idea of WS-Addressing spoofing.
IV. CONCEPT FOR A WEB SERVICES PENETRATION
TESTING TOOL
This section describes the basic idea of the Web Services
penetration testing tool WS-Attacker and deals with its re-
quirements from different points of view.
A. Requirements for Plugin Developers
The requirements for plugin developers can be summarized
to the following aspects:
1) It must be easy to implement new attacks, where each
attack is represented by a WS-Attacker plugin.
2) Any attack category must be supported (spoofing at-
tacks, Denial of Service, etc.)
3) Open for extension: there must be support even for
prospective, not yet invented, attacks.
In general, a plugin author has the task to create the attack-
plugin without knowing WS-Attacker’s internals. It must be
as easy as possible to create new attacks and any kind of
attacks must be supported. This is why WS-Attacker will only
provide a plugin interface and some helper classes each
attack request must be sent by the plugin itself.
B. Requirements for Framework Users
The requirements for framework users must be seen from a
different point of view. They can be summarized as followed:
1) The framework must be easy to use.
2) Only a few clicks should be necessary to test a Web
Service.
3) The users do not need any knowledge about XML
or Web Services and especially, they do not need any
knowledge about XML Security.
A typical WS-Attacker user might be a company, which
provides a Web Service either for their clients, or for its
internal processes. This service should be secure against all
known attacks. By using WS-Attacker, the company can easily
check for vulnerabilities.
C. Processing Steps
For setting up the configuration to attack a Web Service,
the framework will work as follows:
1) The user has to load a WSDL. This can be a local file
or a URL.
2) The framework has to analyze it and extract all possible
operations. Then, the user selects the operation which
will be attacked.
3) The framework must be able to generate a valid request
stub for the selected operation and provide input fields
for message parameters.
4) The user submits a test request. The response to this
request represents the normal state of the Web Service.
Each attack plugin will get this request-response pair as
a reference to build the attack vector.
5) The plugins have to be configured and enabled.
6) The framework runs the enabled plugins.
7) Results generated by the plugins are presented to the
user.
The plugin architecture allows to extend the framework with
new attacks. Each plugin represents exactly one attack and the
framework uses a plugin manager to hold and activate these
plugins. Thus, the main framework responsibilities are parsing
of a WSDL and generating the SOAP request content out of
it. After the attack plugins finish, the framework will present
the results.
D. Framework Results
WS-Attacker distinguishes between three types of results:
1) It displays whether the attack was successful or not.
2) It gives an integer rating to view the impact of the attack.
3) It produces a kind of log entries that can be filtered by
their importance level and may contain additional infos,
e.g. concrete SOAP messages.
It is very important to distinguish between those kinds of
results: The first one is just an indicator for the detection
of a vulnerability in general, so the result will be True or
False. The second one rates the potential risk of an attack. As
an example, a Denial of Service attack might stop a server
for several minutes or even completely so that a reboot is
necessary. Furthermore, the rating can be used to describe the
level of difficulty to apply the attack. The last results can be
seen as an advanced log: Each plugin can produce a Log Entry
which belongs to a display level. The user can then change
this level to filter in and out those entries to view only the
ones he is interested in.
V. WS-ATTACKER IMPLEMENTATION DETAILS
This section gives an overview of implementation details.
A. Overview
The general components of WS-Attacker are shown in
Figure 3. The program is divided into two parts:
Framework: This is the main part of WS-Attacker. Its
task is to set up the environment for attacking Web
Services and manage the processing steps described in
Section IV-C.
Plugin Architecture: WS-Attacker can hold any number
of plugins, where each plugin represents an attack.

Loading a WSDL
Selecting an Operation
Generate Request Content
Submitting a Test Request
Configure Attacks
Start Attacks
Present Results
Attack Plugin 1
Attack Plugin 2
Attack Plugin n
Holds n Plugins
Framework
Plugin Architecture
WS-Attacker
Fig. 3. General overview of WS-Attacker components and processing steps.
B. SoapUI as Back-end
As mentioned in Section IV-C, a Web Service testing
framework like WS-Attacker needs to create requests from a
WSDL, edit the request parameters, and send it to the server.
Using Java, there are a few possibilities for doing this:
1) Implement own classes handling these steps. This in-
cludes building an XML and an XSD parser. To send a
request, some helper methods must be provided unless
the plugin authors want to use raw HTTP sockets.
2) Use the Java SAAJ tools from javax.xml.soap [20]:
This package can manipulate SOAP messages and pro-
vides some helper classes for sending requests.
3) Use a third party solution.
The first approach is very complex and time-consuming. A
lot of tests needs to be created to find bugs. It is just simpler,
faster and safer to rely on standards.
The second approach seems to be very promising, since
it uses standard Java packages and SAAJ is very flexible
for creating and manipulating SOAP messages. Nevertheless,
there are some problems:
1) Each XML element is saved as a single object. However,
especially for Web Service attacks, one must be able to
create malformed messages, e.g. create only open tags
and no end tags. There are also problems when adding
special characters as they are escaped automatically.
2) SAAJ does not provide a WSDL parser, so there is no
possibility to create the basic SOAP request content for
a defined operation.
Where (1) could be wrapped by serializing SAAJ objects
and sending a manual request via custom HTTP sockets,
problem (2) can not be solved as easily as (1).
There are two possibilities for creating a request from a
WSDL. The first one uses the WSDL parser wsdl4java, which
can parse a WSDL file and extract the operation name as well
as the endpoint URI, but which is not able to generate the
SOAP request content. It can only be generated by means of an
XSD parser, which can extract the information from the Types
Testsuite
CurrentInterface
CurrentOperation
CurrentRequest
PluginManager
AbstractPlugin
AbstractOption
Result
GuiView
additional GUI classes
· · ·
Operation Architecture
Plugin Architecture
GUI
Framework
WS-Attacker
Fig. 4. The internal structure of WS-Attacker.
section of a WSDL. The second makes use of the Axis2 tool
wsdl2java. This one can create a request but generates Java
code, giving no direct access to the SOAP request content.
All these problems lead to the third approach: Use a third
party tool: soapUI is the perfect solution for doing this. It is
written in Java. The LGPL license allows to use it for custom
programs. SoapUI is able to parse WSDL files, generate
requests out of it and also to support helper methods for
Basic Authentication, WS-Security etc. Sending requests to
the server is just as easy. SoapUI uses strings to save the
SOAP request content, which allows us to manipulate them
and create malformed requests.
C. Program Structure
A more detailed overview of WS-Attacker’s internal struc-
ture is shown in Figure 4. Mainly, there are two parts: The
Plugin Architecture and the Operation Architecture.
The Operation Architecture represents everything that
has to do with creating Web Service requests and can be
seen as the main part of the framework.
The Plugin Architecture represents the plugin system.
This is the place for the attack plugins.
The Operation Architecture has a Testsuite, which acts like
a wrapper for soapUI. It can load a WSDL and select the
CurrentInterface as well as a CurrentOperation to generate the
CurrentRequest. The CurrentRequest will also be sent to the
Web Service server to learn the normal state and the behavior
on correctly formated messages. Therefore, each attack plugin
can use that response for comparing it to the attack response.
The PluginManager holds all available attack plugins. Each
plugin extends the AbstractPlugin class and can have one or
more AbstractOptions, for example a signature file or some
other configuration parameters. The WS-Attacker GUI will
read these options and present a graphical input method to the
framework user. To distinguish between different data types,
sub-interfaces of AbstractOptions like AbstractOptionInteger
and AbstractOptionBoolean were built.
The results of the attack are collected in the Result object. It
can be compared to an advanced log file, which the GUI will
use to present the results to the user. Results can be filtered by
the plugin source and a level, which indicates how important

Citations
More filters
01 Jan 2014

351 citations

Journal ArticleDOI
TL;DR: Key security properties of the already-deployed Open Charge Point Protocol specifying communication between charging points and energy management systems are studied, arguing that possible subversion or malicious endpoints in the protocol can also lead to destabilization of power networks.
Abstract: One benefit postulated for the adoption of electric vehicles (EVs) is their ability to act as stabilizing entities in smart grids through bidirectional charging, allowing local or global smoothing of peaks and imbalances. This benefit, however, hinges indirectly on the reliability and security of the power flows thus achieved. Therefore, this paper studies key security properties of the already-deployed Open Charge Point Protocol specifying communication between charging points and energy management systems. It is argued that possible subversion or malicious endpoints in the protocol can also lead to destabilization of power networks. While reviewing these aspects, we focus, from a theoretical and practical standpoint, on attacks that interfere with resource reservation originating with the EV, which may also be initiated by a man in the middle, energy theft, or fraud. Such attacks may even be replicated widely, resulting in over- or under-shooting of power network provisioning, or the (total/partial) disintegration of the integrity and stability of power networks.

90 citations


Cites background from "Penetration Testing Tool for Web Se..."

  • ...Other typical threats in c, and particularly in SOAP/XML, are as follows [13]: (Distributed) DoS where attackers might, for example, lead buffer overflow attacks or exhaust the memory of parsers in CSs/CPs; SOAPAction spoofing with obfuscation actions within the body of the HTTP request to bypass authentication mechanisms and firewalls; WS-addressing spoofing with different request and response endpoints; or XML injection, modification or delays by sending oversized payloads (e....

    [...]

Journal ArticleDOI
TL;DR: An in-depth study of the various types of the DoS attacks proposed for the cloud computing environment and classifies them based on the cloud components or services, which they target.
Abstract: Denial-of-service DoS attacks are one of the major security challenges in the emerging cloud computing models. Currently, numerous types of DoS attacks are conducted against the various cloud services and resources, which target their availability, service level agreements, and performance. This paper presents an in-depth study of the various types of the DoS attacks proposed for the cloud computing environment and classifies them based on the cloud components or services, which they target. Besides, it provides a comprehensive analysis of the vulnerabilities utilized in these DoS attacks and investigates about the state-of-the-art solutions presented in the literature to prevent, detect, or deal with each kind of DoS attacks in the cloud. Finally, it presents open research issues. Copyright © 2016 John Wiley & Sons, Ltd.

85 citations

Journal ArticleDOI
TL;DR: An overview on Pentest is provided, showing its application scenarios, models, methodologies, and tools from published papers, to help researchers and people that work with security to understand the aspects and existing solutions related to Pentest.
Abstract: Several studies regarding security testing for corporate environments, networks, and systems were developed in the past years. Therefore, to understand how methodologies and tools for security testing have evolved is an important task. One of the reasons for this evolution is due to penetration test, also known as Pentest. The main objective of this work is to provide an overview on Pentest, showing its application scenarios, models, methodologies, and tools from published papers. Thereby, this work may help researchers and people that work with security to understand the aspects and existing solutions related to Pentest. A systematic mapping study was conducted, with an initial gathering of 1145 papers, represented by 1090 distinct papers that have been evaluated. At the end, 54 primary studies were selected to be analyzed in a quantitative and qualitative way. As a result, we classified the tools and models that are used on Pentest. We also show the main scenarios in which these tools and methodologies are applied to. Finally, we present some open issues and research opportunities on Pentest.

47 citations

Journal ArticleDOI
TL;DR: This work improves upon previous results by providing more efficient techniques to generate XML injection attacks, and investigates four different algorithms and two different fitness functions.
Abstract: Modern enterprise systems can be composed of many web services (e.g., SOAP and RESTful). Users of such systems might not have direct access to those services, and rather interact with them through a single-entry point which provides a GUI (e.g., a web page or a mobile app). Although the interactions with such entry point might be secure, a hacker could trick such systems to send malicious inputs to those internal web services. A typical example is XML injection targeting SOAP communications. Previous work has shown that it is possible to automatically generate such kind of attacks using search-based techniques. In this paper, we improve upon previous results by providing more efficient techniques to generate such attacks. In particular, we investigate four different algorithms and two different fitness functions. A large empirical study, involving also two industrial systems, shows that our technique is effective at automatically generating XML injection attacks.

34 citations


Cites methods from "Penetration Testing Tool for Web Se..."

  • ...[49] presented an automated penetration testing approach and evaluated it on several web service frameworks....

    [...]

References
More filters
01 Jan 1999
TL;DR: This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol, which provides communications privacy over the Internet by allowing client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
Abstract: This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

1,956 citations


"Penetration Testing Tool for Web Se..." refers methods in this paper

  • ...This allows to use SSL/TLS [19] as a secure transport mechanism....

    [...]

01 Jan 2007
TL;DR: This specification defines the core language which can be used to describe Web services based on an abstract model of what the service offers, and defines the conformance criteria for documents in this language.
Abstract: This document describes the Web Services Description Language Version 2.0 (WSDL 2.0), an XML language for describing Web services. This specification defines the core language which can be used to describe Web services based on an abstract model of what the service offers. It also defines the conformance criteria for documents in this language.

847 citations


"Penetration Testing Tool for Web Se..." refers methods in this paper

  • ...For setting up the configuration to attack a Web Service, the framework will work as follows: 1) The user has to load a WSDL....

    [...]

  • ...Thus, the main framework responsibilities are parsing of a WSDL and generating the SOAP request content out of it....

    [...]

  • ...There are two possibilities for creating a request from a WSDL....

    [...]

  • ...2) SAAJ does not provide a WSDL parser, so there is no possibility to create the basic SOAP request content for a defined operation....

    [...]

  • ...SoapUI is able to parse WSDL files, generate requests out of it and also to support helper methods for Basic Authentication, WS-Security etc. Sending requests to the server is just as easy....

    [...]

Proceedings ArticleDOI
03 Jan 2005
TL;DR: This paper introduces a novel approach for declaring information object related access restrictions, based on a valid XML encoding, and shows, how the access restrictions can be declared using XACML and Xpath.
Abstract: Web Services, as the new building blocks of today's Internet provide the power to access distributed and heterogeneous information objects, which is the base for more advanced use like in electronic commerce. But, the access to these information objects is not always unrestricted. The owner of the information objects may control access due to different reasons. This paper introduces a novel approach for declaring information object related access restrictions, based on a valid XML encoding. The paper shows, how the access restrictions can be declared using XACML and Xpath. Based on the specified 'fine grained' policies, multiple policies can be applicable. If these policies declare positive and negative permissions for the same subject, policy inconsistencies exist. The paper also focuses on specifying the ground of policy inconsistencies and how to solve them.

731 citations

Book
21 Feb 2003
TL;DR: Explains how to implement secure Web services and includes coverage of trust, confidentiality, cryptography, authentication, authorization, and Kerberos.
Abstract: Explains how to implement secure Web services and includes coverage of trust, confidentiality, cryptography, authentication, authorization, and Kerberos. You’ll also find details on Security Assertion Markup Language (SAML), XML Key Management Specification (XKMS), XML Encryption, Hypertext Transfer Protocol-Reliability (HTTP-R) and more. Table of contents Part I: Introduction 1: Presenting Web Services 2: Presenting Security 3: New Challenges and New Threats Part II: XML Security 4: XML Signature 5: XML Encryption 6: SAML 7: XACML 8: XML Key Management Specification (XKMS) Part III: Security in SOAP: Presenting WS-Security 9: WS-Security Part IV: Security in Web Services Frameworks 10: .NET and Passport 11: The Liberty Alliance Project 12: UDDI and Security Part V: Conclusion 13: ebXML 14: Legal Considerations A: Case Studies

479 citations

01 Jan 2003
TL;DR: An exhaust gas recirculator in an internal combustion engine wherein a part of the exhaust gas is supplied to a suction manifold only at the time when the throttle valve is opened and in some time interval immediately after the time afterwards.
Abstract: An exhaust gas recirculator in an internal combustion engine wherein a part of the exhaust gas is supplied to a suction manifold only at the time when the throttle valve is opened and in some time interval immediately after the time afterwards, and the supply of the exhaust gas is stopped in time interval in the steady operation of the engine at the degree of opening of the throttle valve in the above supply period.

445 citations


"Penetration Testing Tool for Web Se..." refers background in this paper

  • ...2) Encrypt and decrypt (parts of) SOAP messages using XML Encryption....

    [...]

  • ...Using XML Encryption to XML data ensures its confidentiality....

    [...]

  • ...We mention e.g. Denial of Service and XML Signature Wrapping attacks, or attacks on XML Encryption....

    [...]

  • ...The resulting standards have become XML Encryption [16] and XML Signature [17]....

    [...]

Frequently Asked Questions (2)
Q1. What contributions have the authors mentioned in the paper "Penetration testing tool for web services security" ?

Naturally, this has been followed by a rise in large number of Web Services attacks. In this paper the authors give an overview of their design decisions and provide evaluation of four Web Services frameworks and their resistance against WS-Addressing spoofing and SOAPAction spoofing attacks. 

The future work will cover a large number of other Web Service specific attacks, which bring additional design and implementation challenges. Additionally, an extension of their framework can be seen in the direction of Single Sign-On, which is typically realized using the XML-based SAML specification. The authors hope that usage of WS-Attacker will force the developers to harden their services and make the area of secure Web Services more attractive and accessible also for smaller companies.