Paper Title (use style: paper title)

hungryhorsecabinΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 5 μήνες)

85 εμφανίσεις

International Journal of Computer Information Systems,
Vol. 2, No. 4, 2011

Position of Signed Element for SOAP Message
Tawfiq S. Barhoom, Raed S. K. Rasheed
Faculty of Information Technology
Islamic University of Gaza
Gaza, Palestine
{tbarhoom, rrasheed}

Abstract— Web service is one of the most rapidly developed
technologies in the evolution. Web security service is an
important matter that must be observed, especially at the level of
communicating messages. Simple Object Access Protocol (SOAP)
is the protocol used for communicating messages. We focus on
the Integrity of SOAP messages. In this paper, we propose a new
header in SOAP message containing the signed elements positions
in the message. This header is added to the SOAP message after
the detection of signed elements positions located in the
Document Object Model (DOM) tree, an implementation was
Keywords-component; Web Service, SOAP message, SOAP
message integrity, XML Rewriting Attack.
Communication through the Internet is the most effective
and fastest way at all. It has become the best way to
communicate not only among humans but also between
applications. These applications can communicate via reliable
technologies such as web services. The existence of standards
such as SOAP protocol makes communication with various
platforms became easier. This protocol supports the delivery of
SOAP messages that carry data from the sender to the receiver.
In cases of communication the issue of security should be taken
into account, which lies in three main properties
confidentiality, integrity and availability. While there are
security standers related to web service specifications like WS-
Security and, WS-Policy, the abuse of these standers will cause
a vulnerable system. SOAP messages used to communicate
web services, they are XML documents. There is much
vulnerability in XML documents. One of these vulnerabilities
is XML rewriting which means injecting the XML document
with new elements to modify it. This technique can be used to
attack the SOAP message maliciously using unauthorized
access. The remaining sections of the paper are organized as
follows. In section II we introduce the definitions. In section III
we present the related works. In section IV problem is
discussed. A solution of the problem is presented in section V.
The empirical works discussed in section VI. Finally in section
VII we conclude our discussion.
A. SOAP Message
Simple Object Access Protocol (SOAP) is a lightweight
protocol intended for exchanging structured information in a
decentralized, distributed environment. It uses XML
technologies to define an extensible messaging framework,
providing a message construct that can be exchanged over a
variety of underlying protocols. The framework has been
designed to be independent of any particular programming
model and other implementation specific semantics [13].
A SOAP message is encoded as an XML document,
consisting of an Envelope, Header, Body and Fault elements.
The <Envelope> is the root element in every SOAP message,
and containing two child elements, an optional <Header> and a
mandatory <Body>. The SOAP <Header> is an optional sub-
element of the SOAP envelope, which can be used to pass
application-related information that is to be processed by
SOAP nodes along the message path. The SOAP <Body> is a
mandatory sub-element of the SOAP envelope, which contains
information intended for the ultimate recipient of the message.
The SOAP <Fault> is a sub-element of the SOAP body, used
for reporting errors. With the exception of the <Fault> element,
which is contained in the <Body> of a SOAP message,
Fig. 1(a) depicts the main elements of a SOAP message.
Fig. 1(b) depicts sample of a SOAP message document [12].
B. XML Rewriting Attack - XRA
XML Rewriting Attack is a general name for a distinct type
of attacks based on the malicious interception, manipulation,
and transmission of SOAP messages in a network of
communicating systems. Fig. 2 depicts SOAP message before
attacking, using security and signed elements. Fig. 3 depicts
how the attacker rewrites SOAP message functions by copying
the old body and passing it into a new header. The signed
element of Id 1 is still valid. Using WS-Security [11], WS-
Policy and other standards correctly on SOAP we can avoid
XML rewriting attacks [1] [3]. However, in practice, incorrect
deployment of these standards leads to significant vulnerable
cases [9].

International Journal of Computer Information Systems,
Vol. 2, No. 4, 2011



Figure 1. The elements of a SOAP message.
Many works proposed to detect this kind of attacks. Each of
them has its own limitations. The authors of [2] present the
kinds of attacks that can modify the SOAP message such as
XML rewriting and signature’s weakness and discuss their
existing solutions then they shows the limitations of these
solutions. Finally they propose ideas to secure SOAP message.
There are many mechanisms that have been previously
proposed in order to secure web service communications.
SOAP Account proposed by Rahaman et al [9] [7] is an inline
approach that takes into account information about the structure
of the SOAP message by adding a new header element called
SOAP Account, WS-Policy [14] if used correctly can prevent
such attacks, WSE Policy Advisor by Bhargavan et al [3] takes
the policy and configuration files of WSE, runs several static
queries and generates security reports as well as remedial
actions for security flaws. Formal method by is a scripting
language that formally specifies web service security protocols
and analyzes their security vulnerability [2]. Damiani et al [4]
propose a new structure in the SOAP message to deal with
authorizations and using access control for web service, Sinha
et al [6] discuss new limitations of existing web service
security in providing end to end integrity of multiple signed
messages in a SOAP message in a document production
workflow environment. Rahaman et al [8] discuss how SOAP
Account solution could be applied for early detection of XML
rewriting attacks specifically regarding secure SOAP-based
conversations. They study the performance of SOAP Account
and compare it with WS* policy based. Ghossoon et al [10] use
an encryption approach to prevent attacks of the SOAP
message by intruders when exchanging data between server
and clients. They use the Rijndael method with an encryption
key of 256 bits length for the encryption algorithm. Gajek et al
[5], proposed fixing the inline approach by retuning XPath with
position information, but these proposals are not sufficient to
detect all types of XML rewriting attack. Benameur et al [2]
present explanation for several kinds of attacks that can modify
SOAP message and touch the SOAP vulnerability such as
signature’s weakness and XML rewriting. They make some
recommendations that need to be taken into account to ensure
integrity of SOAP messages.

Figure 2. SOAP message before XML rewriting.
Figure 3. SOAP message after XML rewriting.
All the solutions proposed previously either too complex
and need long processing time or are very simple but
vulnerable. For example, encryption solutions require a lot of
processing which affects performance. On the other hand
proposed solution must be simple and do not require long
processing and cannot be exploited. For simplicity, as we
mentioned previously that the SOAP message is an XML
document and can be exploited through XML rewriting attacks.
We need an idea for SOAP message integrity to be simple and
effective and should not be exploited. The inline approach
proposed by Rahaman et al [7] is a very good solution for
SOAP message integrity. But one of the weaknesses of this
approach is that the SOAPAccount is only preserves the
relationship of an element with its parent and siblings elements.
This is a relative position in the DOM tree. To mitigate the
International Journal of Computer Information Systems,
Vol. 2, No. 4, 2011



vulnerability, one recommendation is to consider in
SOAPAccount the absolute path to the root element (“vertical
fixing”) and to its siblings (“horizontal fixing”) [5]. Fig. 4
depicts the weakness and how an attacker can modify the
SOAP message by copying the envelope into another header
and how the SOAPAccount cannot detect this attack.
Figure 4. SOAP Account cannot detect the attack.
Figure 5. SOAP message as tree and its weakness.
Figure 6. Element positions using pos-order traversal.
SOAP message is an XML document, which we can represent
by using a tree structure, Fig. 5(a) depicts the SOAP message
represented as tree. Fig. 5(b) depicts the SOAP message
weakness, after the attack, the signed elements still valid and
cannot detect the attack. So to detect attacks like this, look at
SOAP message as a structure tree, therefore we will observe
that we can determine the position of all tree nodes easily and
early after creating SOAP message directly. For example,
attacker replaces the body element consisting IBM quote
symbol with a new body element consisting MBI quote symbol
which means the ultimate receiver will process the new body,
and ignore the original one.
Using a post-order traversal by visiting left node first, then
right node, and finally root node, we can obtain the element
position as shown in Fig. 6. According to the importance of the
signed elements we will create a new header called
<SignedElements> that consists of an envelope tag position
called <PositionOfEnvelope>, a body tag position called
<PositionOfBody> and an element tag called
<PositionOfSigned> for each signed element in the SOAP
message, then we will stores the position of the signed element.
The structure of the proposed header will contain only the
signed elements positions. The proposed header for SOAP
message example in Fig. 7(a) after adding <SignedElements>
will be:
<EnvelopePosition>13</ EnvelopePosition >
<BodyPosition>12</ BodyPosition >
<SignedElementPosition1>12</ SignedElementPosition1>
<SignedElementPosition2>3</ SignedElementPosition2>
If the attacker modifies the SOAP message easily we can
observe the change of the location of the signed elements. The
change of element positions is shown in Fig. 7(b). To achieve
the proposed solution the following steps must be performed:
1. On the sender side SOAP message generator generate
SOAP envelop that satisfies its policy.
2. setElementPosition module Adds <SignedElements>
information into the outgoing SOAP message.
3. Sender must sign the <SignedElements> header.
4. On the receiver side SOAP envelope is accepted as valid.
5. checkElementPosition module checks the validation of
<SignedElements> header.
International Journal of Computer Information Systems,
Vol. 2, No. 4, 2011





Figure 7. SOAP message element positions (a) before attack (b) after attack.
Figure 8. Message flow using the proposed solution
The main idea of the proposed header is to add the signed
element position, so we write the function setElementPosition
which creates <SignedElements> header in the SOAP message,
detects the envelope, body and all signed elements positions
and adds these positions into the header. The function
checkElementPosition checks the validation of the element
positions. Fig. 8 depicts where the developed functions
setElementPosition and checkElementPosition are located into
the overall message flow, the functions are shown in Fig. 9.
Description of message flow shown in Fig. 8:
1. Request for tokens.
2. Get tokens to add to SOAP messages.
3. Sending to Policy Module.
4. Sending SOAP message to addElementPosition module.
5. Sending signed message with <SignedElements> header.
6. Received SOAP message.
7. Enforcing WS-Policy.
8. Validate tokens.
9. Receive response from Web Service.
After applying the proposed method on several SOAP
messages and producing SOAP messages with
<SignedElements>, the method used to detect the attack which
could not be detected using other approaches. The attacked
SOAP message at Fig. 11 and the result of
checkElementPosition function is presented in Fig. 13. The
function checkElementPosition detects the attack and presents
an error where a wrong element position related to the current
node position is faced. After applying the proposed method on
several SOAP messages and producing SOAP messages with
<SignedElements>, the method used to detect the attack which
could not be detected using other approaches. The attacked
SOAP message at Fig. 11 and the result of
checkElementPosition function is presented in Fig. 10. The
function checkElementPosition detects the attack and presents
an error where a wrong element position related to the current
node position is faced. For example the first line of Fig. 10
shows that the current position of <soap:Envelope> element is
45, while the actual position is 22 which mean that there is an
Figure 9. Function code: (a) setElementPosition (b) checkElementPosition.
International Journal of Computer Information Systems,
Vol. 2, No. 4, 2011

Figure 10. The result after checkElementPosition check the attacked SOAP
Figure 11. The attacked SOAP Message.
There are various of solutions for XML rewriting attacks.
These solutions either complex or simple but still vulnerable. A
simple proposed solution discussed, this solution consists of
adding a new header into SOAP message called
<SignedElements> that points to the signed elements,
validating <SignedElements> by detecting any modification of
SOAP message caused by XML rewriting attacks. The
functions setElementPosition and checkElementPosition were
implemented. The first is used to set the proposed header and
the second is used to detect the attacks.
[1] Bajaj, et al., Web Services Policy Framework (WS-Policy), September,
[2] Benameur A., Abdul Kadir F., and Fenet S. XML Rewriting Attacks:
Existing Solutions and their Limitations. In IADIS Applied Computing
2008. IADIS Press, Apr. 2008.
[3] Bhargavan K., Fournet C., Gordon A., and O'Shea G., An advisor for
web services security policies, Proceedings of the 2005 workshop on
Secure web services, November 11-11, 2005, Fairfax, VA, USA.
[4] Damiani E., Vimercati S., Paraboschi S., Samarati P., Securing SOAP E-
Services, International Journal of Information Security, 2001, Volume 1,
Number 2, Pages 100-115,November 2001.
[5] Gajek S., Liao L., Schwenk J., Breaking and fixing the inline approach,
Proceedings of the 2007 ACM workshop on Secure web services,
November 02-02, 2007, Fairfax, Virginia, USA.
[6] Kumar Sinha, S.; Sinha, S. , "Limitations of Web Service Security on
SOAP Messages in a Document Production Workflow Environment,"
Advanced Computing and Communications, 2008. ADCOM 2008. 16th
International Conference on , vol., no., pp.342-346, 14-17 Dec. 2008.
[7] Rahaman M., Marten R., and Schaad A. An inline approach for secure
soap requests and early validation. OWASP AppSec Europe, 2006.
[8] Rahaman M. and Schaad A.. Soap-based secure conversation and
collaboration. In ICWS, pages 471-480, 2007.
[9] Rahaman M., Schaad A., Rits M., Towards secure SOAP message
exchange in a SOA, Proceedings of the 3rd ACM workshop on Secure
web services, November 03-03, 2006, Alexandria, Virginia, USA.
[10] Waleed, G.M.; Ahmad, R.B.; , "Security protection using simple object
access protocol (SOAP) messages techniques," Electronic Design, 2008.
ICED 2008. International Conference on , vol., no., pp.1-6, 1-3 Dec.
[12] SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) W3C
Recommendation 27, April, 2007
[13] Web Service Security Policy, 2005.


Dr. Tawfiq S. Barhoom



ai Jiao Tong University


This author is
ead of
r science department
aculty of IT,
Islamic University

His current interest
research include Design Patterns, Secure
Software, Modeling, XMLs security, Web
services and its Applications



Mr. Raed S. Rasheed


assistance in
software development department
aculty of
IT, Islamic University

His current
interest research include XML security, web
services, computer vision and multimedia.