Copyright © 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 OWASP AppSec Europe May 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,andreas.sch +33 ( 0 )

OWASP AppSec Europe 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 Goals of this work 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. 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.

OWASP AppSec Europe Today’s security mechanisms 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. Request -er of a service Interm- ediary Web service Security Context Figure : Point-to-point Configuration Secure Socket Layer (SSL) along with the de facto Transport Layer Security (TLS) provides transport level security for web services applications.

OWASP AppSec Europe What do we need in Web service security?  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. Request- er of a service Interme -diary Web service Figure : End-to-End Configuration Security Context WS-Security along with some other standards like WS-Policy address these issues. We need Message Level Security for web services because:

OWASP AppSec Europe  Realization of WS-Security and Related standards

OWASP AppSec Europe Architecture of Web Services Security WS-Policy describes the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms) WS-SecureConversation describes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys Requester Web Service Security Token Service Policy Security Token Claims Policy Security Token Claims Security Token Claims 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 WS-Trust describes a framework for trust models that enables Web services to securely interoperate

OWASP AppSec Europe “Alice" "mTbzQM84RkFqza+lIes/xw==" " T13:31:50Z" "U9sBHidIkVvKA4vZo0gGKxMhA1g=“ "8/ohMBZ5JwzYyu+POU/v879R01s=" “SAP" "ORACLE" UsernameToken assumes both parties know Alice’s secret password p Securing SOAP Messages using WS-Security Each DigestValue is a cryptographic hash of the URI target hmacsha1(key, SignedInfo) where key  psha1(p+nonce+created) header defined by OASIS WS-Security includes identity tokens, signatures, encrypted message parts “SAP" “ORACLE" Soap Message to send Soap Message after addition of Security Header N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.

OWASP AppSec Europe Message flow using WS*Standards 3.Sending to Policy Module 4. Sign/Encrypt & send SOAP message to web service Web Service Requester Web Service Provider Security Token service 2. Get tokens to add to SOAP messages 7. Receive response from Web Service Figure: Typical message flow between web services using WS-Security Incorporating WS-Policy in SOAP 6. Validate tokens Checking SOAP according to WS- Policy 5.Enforcing WS-Policy 1. Request for tokens

OWASP AppSec Europe  XML Rewriting Attacks

OWASP AppSec Europe A XML Rewriting Attack From: Rahim To: Bookshop Action: “Buy Jabbar’s book” (signed by Rahim) Rahim’s mobile Online Book shop (Web Service) Attacker Sent: Monday From: Rahim To: Bank Action: “Pay Charlie $20” (signed by Rahim) Sent: Tuesday From: Rahim To: Bank Action: “Buy Charlie’s book” (signed by Rahim) Sent: Wednesday From: Rahim To: Bookshop Action: “Buy Jabbar’s book” (signed by Rahim) Attacker may update and replay envelopes to confuse Book Shop XML Rewriting attack is a general name to a class of attacks (e.g. Replay, man-in-middle, redirection, and dictionary) on SOAP messages.

OWASP AppSec Europe A Signed SOAP Message Before... Rahim cGxr8w2AnBUzuhLzDYDoVw== T16:49:45Z Ego0... vSB9JU/Wr8ykpAlaxCx2KdvjZcc= Karim 1000 Message to bank’s web service says: “Transfer $1000 to karim, signed by Rahim” Bank can verify the signature that has been computed using key derived from Rahim’s secret password N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.

OWASP AppSec Europe and After an XML Rewriting Attack Rahim cGxr8w2AnBUzuhLzDYDoVw== T16:49:45Z Ego0... vSB9JU/Wr8ykpAlaxCx2KdvjZcc= Although Rahim’s password has not been broken, the message now reads “Transfer $5000 to Charlie, signed Rahim” Charlie(Attacker) has intercepted and rewritten this message The indirect signature of the body, now hidden in BogusHeader, may still appear valid N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity. Karim 1000 Charlie 5000

OWASP AppSec Europe  Conceptual Solution and Proposed Technique

OWASP AppSec Europe 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 SOAP Account Number Of Child Elements of Envelope Number Of Header Elements in SOAP Header Successor And Predecessor Relationship of Each Signed Object Number Of References in each signature Element Parent Element Sibling Elements Sucessor And Predecessor Relationship Extentsion For Future Figure : SOAP Account 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 Structure/Account keeps the record of a SOAP message’s structure of elements.

OWASP AppSec Europe Message flow in proposed technique 7.Enforcing WS-Policy 5. Sending signed message with SOAP Account Information 3.Sending to Policy Module 6. Received SOAP message Web Service Requester Web Service Provider Security Token service 2. Get tokens to add to SOAP messages 4. Sending SOAP message to SOAPAccount module 9. Receive response from Web Service Figure: Message flow using new approach between web services Adding SOAP Account Info Validating SOAP Account Info Incorpor-ating WS-Policy in SOAP Checking SOAP according to WS- Policy 1. Request for tokens 8. Validate tokens

OWASP AppSec Europe A SOAP message after adding SOAP Account ………… Alice cGxr8w2AnBUzuhLzDYDoVw== T16:49:45Z Ego0... Qser99... OUytt0... vSB9JU/Wr8ykpAlaxCx2KdvjZcc= 2 Bob 1000 Message to bank’s web service says:”Transfer 1000 euro to Bob,signed Alice” Verifying signature using key derived from Alice’s secret password

OWASP AppSec Europe A SOAP request after an attempt to attack (Excerpt) ……………. Alice cGxr8w2AnBUzuhLzDYDoVw== T16:49:45Z Ego0... Qser99... OUytt0... vSB9JU/Wr8ykpAlaxCx2KdvjZcc= 2 Bob 1000 Bob 5000 Attacker has intercepted the message This reference is not valid anymore because No of header is not 2. After attack it is 3 Attacker has added a BogusHeader & included the Body Amount has been changed to 5000 by the attacker

OWASP AppSec Europe 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 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 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.

OWASP AppSec Europe 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 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.