Inline Approach for Secure SOAP Requests and Early Validation

OWAS P AppSe c Europ e
May 2006

Mohammad Ashiqur Rahaman, Maartin Rits and Andreas Schaad SAP Research, Sophia Antipolis, France {mohammad.ashiqur.rahaman,maarten.rits,andr eas.schaad} +33 ( 0 )4 92 28 62 00

Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

The OWASP Foundation

Topics of the Presentation  Goals of this work  Today’s security mechanisms and Web Services Security  Realization of WS-Security Features  XML Rewriting Attacks  Conceptual solution and proposed technique  Performance evaluation  Conclusion and future work
OWASP AppSec Europe 2006

Goals of this work
To analyze the work that has been done in Web Service security and related area and to be able to find out the drawbacks, vulnerabilities and remedy against security attacks.

Explore and analyze WS-Security and related (e.g. WSPolicy, WS-SecurePolicy,..) specifications. Analyze the application of formal methods in WS-Security standards verification. Implement the integrity features of WS-Security into Johnson2. Explore XML rewriting attacks against web services. Realize the measures against these attacks and evaluate the performance of the state of the art approach against these attacks. Propose a scheme to detect these attacks in an efficient way.
OWASP AppSec Europe 2006

Today’s security mechanisms
Secure Socket Layer (SSL) along with the de facto Transport Layer Security (TLS) provides transport level security for web services applications.

• Limitations:
Not granular enough se it. Inflexible about routing. No chance for auditing what’s going on. Can’t avoid repudiation. HTTP might not be the only transport that is used now a day.
Security Context Security Context

Request -er of a service


Web service

Figure : Point-to-point Configuration

OWASP AppSec Europe 2006


What do we need in Web service security?

We need Message Level Security for web services because: Point of interaction is more “over the internet”. Interaction between partners with no previously established relationship. RequestProgram to program Interme Web er of a -diary service service interaction. More dynamic interaction. We need fine grained Figure : End-to-End Configuration signature and encryption.
Security Context

WS-Security along with some other standards like WS-Policy address these issues.
OWASP AppSec Europe 2006

Realization of WS-Security and Related standards

OWASP AppSec Europe 2006


Architecture of Web Services Security
describes a framework for trust models that enables Web services to securely interoperate

Claims Policy Security Token

Security Token Service

describes the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms)



Claims Security Token

Web Service
Security Token


how to attach signature and encryption headers to SOAP messages how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages

describes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys

OWASP AppSec Europe 2006


Securing SOAP Messages using WS-Security
Soap Message to send
<Envelope> <Header/> <Body Id=2> <StockQuoteRequest> <symbols> <Symbol>“SAP" <Symbol>“ORACLE" </Envelope>

Soap Message after addition of Security Header
<Envelope> UsernameToken assumes both <Header> parties know Alice’s secret <Security> password p <UsernameToken Id=1> <Security> <Username>“Alice" header defined by <Nonce>"mTbzQM84RkFqza+lIes/xw==" OASIS WS<Created>"2004-09-01T13:31:50Z"DigestValue is a Each Security includes <Signature> cryptographic hash of the identity tokens, <SignedInfo> URI target signatures, <SignatureMethod Algorithm=hmac-sha1> encrypted <Reference URI=#2> message parts <DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“ <SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s=" <KeyInfo> <SecurityTokenReference> <Reference URI=#1 ValueType=UsernameToken> hmacsha1(key, SignedInfo) <Body Id=2> where <StockQuoteRequest> key≈ psha1(p+nonce+created <symbols> ) <Symbol>“SAP" <Symbol>"ORACLE"

N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.
OWASP AppSec Europe 2006

Message flow using WS*Standards
1. Request for tokens
2. Get tokens to add to SOAP messages

Security Token service

Checking SOAP according to WSPolicy

Web Service Requester

6. Validate tokens 3.Sending to Policy Module 5.Enforcing WS-Policy
4. Sign/Encrypt & send SOAP message to web service

Incorporating WS-Policy in SOAP

7. Receive response from Web Service

Web Service Provider

Figure: Typical message flow between web services using WS-Security
OWASP AppSec Europe 2006

XML Rewriting Attacks

OWASP AppSec Europe 2006


A XML Rewriting Attack
XML Rewriting attack is a general name to a class of attacks (e.g. Replay, man-in-middle, redirection, and dictionary) on SOAP messages.

From: Rahim To: Bookshop Action: “Buy Jabbar’s book” (signed by Rahim) Rahim’s mobile Attacker

Sent: Tuesday Sent: Monday From: Rahim From: Rahim To: Bank To: Bank Sent: Wednesday Action: “Buy Action: “Pay Charlie $20” Charlie’s From: Rahim Rahim) book” (signed by To: Bookshop (signed by Rahim) Action: “Buy Jabbar’s book” (signed by Rahim)

Online Book shop (Web Service)

Attacker may update and replay envelopes to confuse Book Shop
OWASP AppSec Europe 2006

A Signed SOAP Message Before...
<Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Rahim</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> Bank can verify the <Signature> signature that has <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</>been computed <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> using key derived <KeyInfo> from <SecurityTokenReference><Reference URI=#2/> Rahim’s secret <Body Id=1> password <TransferFunds> <beneficiary>Karim</> <amount>1000</>

Message to bank’s web service says: “Transfer $1000 to karim, signed by Rahim”

N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.
OWASP AppSec Europe 2006

and After an XML Rewriting Attack
<Envelope> intercepted and rewritten <Header> this message <Security> <UsernameToken Id=2> <Username>Rahim</> The indirect signature <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> of the body, now hidden <Created>2003-02-04T16:49:45Z</> in BogusHeader, may <Signature> still appear valid <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/> <BogusHeader> <Body Id=1> Although Rahim’s <TransferFunds> password has not been <beneficiary>Karim</> <amount>1000</> broken, the message <Body> now reads “Transfer <TransferFunds> $5000 to Charlie, <beneficiary>Charlie</> signed Rahim” <amount>5000</>

Charlie(Attacker) has

N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.
OWASP AppSec Europe 2006

Conceptual Solution and Proposed Technique

OWASP AppSec Europe 2006


Conceptual solution against XML rewriting attacks
 After carefully observing the rewriting attacks the following things are obvious: All attacks are some kind of modification of SOAP message. The intended predecessor or successor relationship of the SOAP element is lost consequently. The number of predecessor, successor, and sibling elements of a SOAP element where the unexpected modification occurs is changed and thus the expected hierarchy of the element is modified as well.

We capture these observations in a new header, we call it SOAP Account
OWASP AppSec Europe 2006

SOAP Account
SOAP Structure/Account keeps the record of a SOAP message’s structure of elements.

At the time of sending SOAP message we can always keep an account of SOAP elements by including SOAP Account into the message: Number of child elements of root. Number of header elements. Number of references for signing element. Predecessor, successor, and sibling relationship of the signed object. ………. The sender must sign the SOAP Account Information.

SOAP Account Number Of Child Elements of Envelope Number Of Header Elements in SOAP Header Number Of References in each signature Element
Successor And Predecessor Relationship of Each Signed Object

Parent Element
Sucessor And Predecessor Relationship

Sibling Elements

Extentsion For Future

Figure : SOAP Account OWASP AppSec Europe 2006

Message flow in proposed technique
1. Request for tokens

Security Token service
2. Get tokens to add to SOAP messages

Checking SOAP according to WS-Policy

Web Service Requester
4. Sending SOAP message to SOAPAccount module
Validating SOAP Account Info

8. Validate tokens 7.Enforcing WS-Policy

3.Sending to Policy Module

Incorpor-ating WS-Policy in SOAP

5. Sending signed message Adding SOAP with SOAP Account Info Account Information

6. Received SOAP message

Web Service Provider
9. Receive response from Web Service

Figure: Message flow using new approach between web services

OWASP AppSec Europe 2006


A SOAP message after adding SOAP Account
<Envelope> Message to bank’s web service says:”Transfer <Header> 1000 euro to Bob,signed Alice” ………… <Security> <UsernameToken Id=3> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <Reference URI= #2><DigestValue>Qser99...</> <Reference URI= #3><DigestValue>OUytt0...</> <SignatureValue> vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#3/> <SoapAccount id=2> <NoChildOfEnvelope>2</> <NoOfHeader > 2 </> </SoapAccount> <Body Id=1> <TransferFunds> Verifying signature using key derived from <beneficiary>Bob</> Alice’s secret password <amount>1000</>

OWASP AppSec Europe 2006


A SOAP request after an attempt to attack (Excerpt)
<Envelope> Attacker has intercepted the message <Header> ……………. <Security> <UsernameToken Id=3> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> This reference is not valid anymore <Signature> header is not 2. After attack it is 3 <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <Reference URI= #2><DigestValue>Qser99...</> <Reference URI= #3><DigestValue>OUytt0...</> <SignatureValue> vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#3/> <SoapAccount id=2> <NoChildOfEnvelope>2</> <NoOfHeader > 2 </> Attacker has added a BogusHeader </SoapAccount> & included the Body <BogusHeader> <Body Id=1> <TransferFunds> <beneficiary>Bob</> <amount>1000</> <Body> Amount has been changed to <TransferFunds> 5000 by the attacker <beneficiary>Bob</> <amount>5000</>

because No of

OWASP AppSec Europe 2006


Inline approach and Efficiency
 Inline Approach
SOAP Account information are computed while creating the SOAP message itself. We use popular XML package model like DOM in the sending and receiving application. Validation of this SOAP Account is done while receiving the SOAP message in the receiving application.  Since we can compute SOAP Account while creating the message & do not incur any considerable overheads, we call this approach as inline.

 Efficiency
 in Inline approach we consciously avoid the XML processing, in particular XML canonicalization, while validating SOAP Account in the SOAP message.

OWASP AppSec Europe 2006


Performance Evaluation
 We evaluate the performance of detecting XML Rewriting Attacks using SOAP Account in the SOAP message. We simulate few XML Rewriting Attack scenarios in Java. Service requester and provider are designed using JWSDP 1.6. We simulate an attacker to generate the attacks.  Evaluation Environment
Executed with Sun’s jdk1.5.0_06, for windows. We use XWS Security Framework of JWSDP 1.6 package for WS-Security features as a comparable message level security implementation. Using a PC with Mobile Intel(R) Pentium(R) 4, 2.80GHz Processor and 512 MB RAM, running on Microsoft Windows XP Professional.

OWASP AppSec Europe 2006


Performance Evaluation-Two
Considering the fact of being not enough for profiling Java code of using System.currentTimeMillis(), we use further a library called “hrtlib.jar” to get another result in the following Figure. This library is simple and it uses a Java Native Interface (JNI) implementation to return a fractional number of milliseconds elapsed since some undetermined moment in the past. This time using SOAP Account we get 4 times better performance than Policy driven solution.
Average Service Time(ms)

Timing Diagram
70 60 50 40 30 20 10 0
ra ti o ns 10 20 30 40 1

PolicyDriven XWS-Security SoapAccount




OWASP AppSec Europe 2006
Num ber Of Iterations



SOAP Structure/Account information has been ignored in detecting XML rewriting attacks so far. The SOAP Account can be incorporated in WSSecurity. We can even use it in any standalone web service which may be subject to XML rewriting attacks.

It is not an attempt to replace policy based validation; rather it is designed to be an alternative that can be used when performance is an issue in detecting XML rewriting attacks.
OWASP AppSec Europe 2006

Future work
How SOAP Account information can be used for securing a session of message exchange could be a future research topic. WS-SecureConversation addresses this issue introducing security contexts, which can be used to secure sessions between two parties. We have used only the XWS-Security Framework as a comparable message level security implementation and have drawn some comparisons of WSE implementation with our technique. It would be interesting to see how the performance scales regarding other implementation frameworks of message level security.
OWASP AppSec Europe 2006

Sign up to vote on this title
UsefulNot useful