Inline Approach for Secure SOAP Requests and Early Validation OWASP AppSec Europe May 2006 Mohammad Ashiqur Rahaman, Maartin Rits and Andreas Schaad SAP Research, Sophia Antipolis, France {mohammad.ashiqur.rahaman,maarten.rits,andreas.scha ad}@sap.com +33 ( 0

Download Report

Transcript Inline Approach for Secure SOAP Requests and Early Validation OWASP AppSec Europe May 2006 Mohammad Ashiqur Rahaman, Maartin Rits and Andreas Schaad SAP Research, Sophia Antipolis, France {mohammad.ashiqur.rahaman,maarten.rits,andreas.scha ad}@sap.com +33 ( 0 

Inline Approach for Secure
SOAP Requests and Early
Validation
OWASP
AppSec
Europe
May 2006
Mohammad Ashiqur Rahaman, Maartin Rits and
Andreas Schaad
SAP Research, Sophia Antipolis, France
{mohammad.ashiqur.rahaman,maarten.rits,andreas.scha
ad}@sap.com
+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
http://www.owasp.org/
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.
OWASP AppSec Europe 2006
3
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
Request
-er of a
service
Security
Context
Intermediary
Web
service
Figure : Point-to-point
Configuration
OWASP AppSec Europe 2006
4
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.
Program to program
interaction.
More dynamic interaction.
We need fine grained
signature and encryption.
Security
Context
Requester of a
service
Interme
-diary
Web
service
Figure : End-to-End
Configuration
WS-Security along with some other standards like WS-Policy address these issues.
OWASP AppSec Europe 2006
5
Realization of WS-Security and Related
standards
OWASP AppSec Europe 2006
6
Architecture of Web Services Security
Claims
WS-Trust
describes a framework
for trust models that
enables Web services to
securely interoperate
Policy
Security
Token
Service
Security
Token
WS-Policy
Policy
Policy
Requester
Claims
Security
Token
WS-Security
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
Web
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)
Security
Token
Claims
WS-SecureConversation
describes how to manage and authenticate
message exchanges between parties
including security context exchange and
establishing and deriving session keys
OWASP AppSec Europe 2006
7
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 password p
<Security>
<UsernameToken Id=1>
<Security> header
<Username>“Alice"
defined by OASIS
<Nonce>"mTbzQM84RkFqza+lIes/xw=="
WS-Security
<Created>"2004-09-01T13:31:50Z" Each DigestValue is a
includes identity
<Signature>
cryptographic hash of the
tokens, signatures,
<SignedInfo>
URI target
encrypted message
<SignatureMethod Algorithm=hmac-sha1>
parts
<Reference URI=#2>
<DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“
<SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s="
<KeyInfo>
<SecurityTokenReference>
<Reference URI=#1 ValueType=UsernameToken>
<Body Id=2>
<StockQuoteRequest>
hmacsha1(key, SignedInfo)
<symbols>
where
<Symbol>“SAP"
keypsha1(p+nonce+created)
<Symbol>"ORACLE"
N.B All the SOAP messages here eliding some headers, all namespaces, and
abbreviating long strings for brevity.
OWASP AppSec Europe 2006
8
Message flow using WS*Standards
1. Request for tokens
Security Token
service
2. Get tokens to add to SOAP messages
Checking SOAP
according to WSPolicy
Web Service
Requester
6. Validate
tokens
5.Enforcing
WS-Policy
3.Sending to
Policy Module
Incorporating
WS-Policy in
SOAP
4. Sign/Encrypt &
send SOAP
message to web
service
7. Receive response from Web Service
Web Service
Provider
Figure: Typical message flow between web services using WS-Security
OWASP AppSec Europe 2006
9

XML Rewriting Attacks
OWASP AppSec Europe 2006
10
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)
Sent: Tuesday
Sent: Monday
From: Rahim
From: Rahim
To: Bank
To: Bank
Sent:
Wednesday
Action: “Pay CharlieAction:
$20” “Buy Charlie’s book”
From:
Rahim
(signed by Rahim) (signed by Rahim)
To: Bookshop
Action: “Buy Jabbar’s book”
(signed by Rahim)
Online Book shop
(Web Service)
Rahim’s mobile
Attacker
Attacker may update and replay
envelopes to confuse Book Shop
OWASP AppSec Europe 2006
11
A Signed SOAP Message Before...
Message to bank’s web service
says: “Transfer $1000 to karim,
signed by Rahim”
<Envelope>
<Header>
<Security>
<UsernameToken Id=2>
<Username>Rahim</>
<Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>
<Created>2003-02-04T16:49:45Z</>
Bank can verify the
<Signature>
<SignedInfo>
signature that has been
<Reference URI= #1><DigestValue>Ego0...</>
computed using key
<SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</>
derived from Rahim’s
<KeyInfo>
secret password
<SecurityTokenReference><Reference URI=#2/>
<Body Id=1>
<TransferFunds>
<beneficiary>Karim</>
<amount>1000</>
N.B All the SOAP messages here eliding some headers, all namespaces, and
abbreviating long strings for brevity.
OWASP AppSec Europe 2006
12
and After an XML Rewriting Attack
Charlie(Attacker) has intercepted
<Envelope>
and rewritten this message
<Header>
<Security>
<UsernameToken Id=2>
<Username>Rahim</>
The indirect signature of the
<Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>
body, now hidden in
<Created>2003-02-04T16:49:45Z</>
BogusHeader, may still
<Signature>
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 now
<Body>
reads “Transfer $5000 to
<TransferFunds>
Charlie, signed Rahim”
<beneficiary>Charlie</>
<amount>5000</>
N.B All the SOAP messages here eliding some headers, all namespaces, and
abbreviating long strings for brevity.
OWASP AppSec Europe 2006
13
Conceptual Solution and Proposed
Technique

OWASP AppSec Europe 2006
14
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
15
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
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 WSPolicy
Web Service
Requester
8. Validate
tokens
4. Sending SOAP
message to
SOAPAccount module
3.Sending to
Policy Module
Incorpor-ating
WS-Policy in
SOAP
Validating SOAP
Account Info
5. Sending signed
message with SOAP
Adding SOAP Account Information
7.Enforcing
WS-Policy
6. Received
SOAP message
Account Info
Web Service
Provider
9. Receive response from Web Service
Figure: Message flow using new approach between web services
OWASP AppSec Europe 2006
17
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 </> Verifying signature using key derived from
</SoapAccount>
Alice’s secret password
<Body Id=1>
<TransferFunds>
<beneficiary>Bob</>
<amount>1000</>
OWASP AppSec Europe 2006
18
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
19
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
20
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
21
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
PolicyDriven XWS-Security
40
30
20
10
1
SoapAccount
N
o
of
Ite
ra
tio
ns
70
60
50
40
30
20
10
0
Number Of Iterations
OWASP AppSec Europe 2006
22
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.
OWASP AppSec Europe 2006
23
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
24