OWASPAppSecEU2006 InlineApproachforSecureSOAPRequests

Inline Approach for Secure
SOAP Requests and Early

Validation
Mohammad Ashiqur Rahaman, Maartin Rits

and Andreas Schaad
SAP Research, Sophia Antipolis, France
{mohammad.ashiqur.rahaman,maarten.rits,andr
eas.schaad}@sap.com
OWAS +33 ( 0 )4 92 28 62 00
P
AppSe
c
Copyright © 2006 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation
Europ License.
e The OWASP
May 2006 http://www.owasp.org/
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 2

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

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

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. Security
Context
Security
Context
No chance for auditing Request
what’s going on. -er of a

service
Interm-
ediary
Web
service
Can’t avoid repudiation.

Figure : Point-to-point
HTTP might not be the Configuration
only transport that is

used now a day.

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 Security
Context
with no previously established

relationship.
Program to program Request-
er of a Interme Web
interaction. service -diary service
More dynamic interaction.

We need fine grained Figure : End-to-End
signature and encryption. Configuration
WS-Security along with some other standards like WS-Policy address these issues.

Realization of WS-Security and
Related standards

Architecture of Web Services Security
Claims
WS-Trust
describes a framework
for trust models that
Policy Security
enables Web services Token
to securely interoperate Security
Token WS-Policy
Service describes the
capabilities and
constraints of the
security (and other
business) policies
on intermediaries
and endpoints (e.g.
required security
Policy Policy tokens, supported
encryption
Web algorithms)
Requester
Service
Claims Security Security Claims
Token WS-Security Token
how to attach signature and encryption
headers to SOAP messages WS-SecureConversation
how to attach security tokens, including describes how to manage and authenticate
binary security tokens such as X.509 message exchanges between parties
certificates and Kerberos tickets, to
messages
including security context exchange and
establishing and deriving session keys
Securing SOAP Messages using WS-Security
Soap Message to send Soap Message after addition of Security Header
<Envelope>
<Envelope> UsernameToken assumes both
<Header/> <Header> parties know Alice’s secret
<Security> password p
<Body Id=2> <UsernameToken Id=1>
<StockQuoteRequest> <Security> <Username>“Alice"
<symbols> header defined by <Nonce>"mTbzQM84RkFqza+lIes/xw=="
OASIS WS- <Created>"2004-09-01T13:31:50Z"
Each DigestValue is a
<Symbol>“SAP" Security includes <Signature>
<Symbol>“ORACLE" cryptographic hash of the
identity tokens, <SignedInfo> URI target
signatures, <SignatureMethod Algorithm=hmac-sha1>
</Envelope> 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.
Message flow using WS*Standards
1. Request for tokens
Security Token
2. Get tokens to add to SOAP messages service
Checking SOAP
according to WS-
Policy
6. Validate
tokens
Web Service
Requester 3.Sending to 5.Enforcing
Policy Module WS-Policy
Incorporating 4. Sign/Encrypt &

send SOAP
WS-Policy in message to web
SOAP service
Web Service
Provider
7. Receive response from Web Service
Figure: Typical message flow between web services using WS-Security

 XML Rewriting Attacks

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.
Sent: MondaySent: Tuesday

From: Rahim From: Rahim
To: Bank To: Bank
From: Rahim Sent: WednesdayAction: $20”
Action: “Pay Charlie “Buy Charlie’s
To: Bookshop From: Rahim book”
(signed by Rahim)
To: Bookshop (signed by Rahim)
Action: “Buy
Action: “Buy Jabbar’s
Jabbar’s book” book”
(signed by Rahim) (signed by Rahim)
Online Book shop
(Web Service)
Rahim’s
mobile
Attacker Attacker may update and

replay envelopes to confuse
Book Shop
A Signed SOAP Message Before...
Message to bank’s web

<Envelope> service says: “Transfer
<Header> $1000 to karim, signed by
<Security>
<UsernameToken Id=2> Rahim”
<Username>Rahim</>
<Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>
<Created>2003-02-04T16:49:45Z</>
<Signature> Bank can verify the
<SignedInfo> signature that has
<Reference URI= #1><DigestValue>Ego0...</>been computed
<SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</>
<KeyInfo>
using key derived
from Rahim’s secret
<SecurityTokenReference><Reference URI=#2/>
<Body Id=1> password
<TransferFunds>
<beneficiary>Karim</>
<amount>1000</>

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

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

SOAP Account
SOAP Structure/Account keeps the record of a SOAP message’s structure of
elements.
At the time of sending SOAP SOAP Account
message we can always keep an Number Of Child Elements of

Envelope
account of SOAP elements by
including SOAP Account into the Number Of Header Elements in SOAP
Header
message:
Number of child elements of Number Of References in each
signature Element
root. Successor And Predecessor Relationship of Each
Number of header elements. Signed Object
Parent Element
Number of references for Sucessor And Predecessor
Relationship
signing element.
Predecessor, successor, and Sibling Elements
sibling relationship of the

signed object. Extentsion For Future
………. Figure : SOAP Account

The sender must sign the SOAP
Account Information. OWASP AppSec Europe 2006 16
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 8. Validate
tokens
4. Sending SOAP Validating SOAP 7.Enforcing
Account Info
message to WS-Policy
3.Sending to SOAPAccount module
Policy Module
5. Sending 6. Received
signed message
SOAP
Incorpor-ating Adding SOAP with SOAP
message
WS-Policy in Account Info Account
Information
SOAP
Web Service
Provider
9. Receive response from Web Service
Figure: Message flow using new approach between web services

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

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

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.

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.

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.
Timing Diagram
Average Service Time(ms)
70
60
50
40 PolicyDriven XWS-Security
30 SoapAccount
20
10
0
ns
ti o
10
20
30
40
1
ra
Ite
of
o

N
Number Of Iterations
Conclusion
SOAP Structure/Account information has been

ignored in detecting XML rewriting attacks so far.
The SOAP Account can be incorporated in WS-
Security.
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.

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.

OWASPAppSecEU2006 InlineApproachforSecureSOAPRequests

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OWASPAppSecEU2006 InlineApproachforSecureSOAPRequests

Enviado por

Direitos autorais:

Formatos disponíveis

Inline Approach for Secure

SOAP Requests and Early

Mohammad Ashiqur Rahaman, Maartin Rits

 Goals of this work

OWASP AppSec Europe 2006 2

Explore and analyze WS-Security and related (e.g. WS-

OWASP AppSec Europe 2006 3

No chance for auditing Request

what’s going on. -er of a

Can’t avoid repudiation.

only transport that is

OWASP AppSec Europe 2006 4

with no previously established

More dynamic interaction.

OWASP AppSec Europe 2006 5

OWASP AppSec Europe 2006 6

Incorporating 4. Sign/Encrypt &

Figure: Typical message flow between web services using WS-Security

OWASP AppSec Europe 2006 9

OWASP AppSec Europe 2006 10

Sent: MondaySent: Tuesday

Attacker Attacker may update and

Message to bank’s web

OWASP AppSec Europe 2006 12

OWASP AppSec Europe 2006 14

All attacks are some kind of modification of SOAP

We capture these observations in a new header, we call it SOAP Account

At the time of sending SOAP SOAP Account

message we can always keep an Number Of Child Elements of

sibling relationship of the

………. Figure : SOAP Account

Security Token service

Figure: Message flow using new approach between web services

OWASP AppSec Europe 2006 17

OWASP AppSec Europe 2006 18

OWASP AppSec Europe 2006 19

OWASP AppSec Europe 2006 20

OWASP AppSec Europe 2006 21

OWASP AppSec Europe 2006 22

SOAP Structure/Account information has been

It is not an attempt to replace policy based validation;

OWASP AppSec Europe 2006 23

OWASP AppSec Europe 2006 24

Você também pode gostar