Inline Approach for Secure SOAP Requests and Early

Inline Approach for Secure SOAP Requests and Early Validation OWASP App. Sec Europe May 2006 Mohammad Ashiqur Rahaman, Maartin Rits and Andreas Schaad SAP Research, Sophia Antipolis, France {mohammad. ashiqur. rahaman, maarten. rits, andreas. sch aad}@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 App. Sec 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. WSPolicy, WS-Secure. Policy, . . ) specifications. Analyze the application of formal methods in WS-Security standards verification. Implement the integrity features of WS-Security into Johnson 2. 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 App. Sec 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 App. Sec 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 Intermediary Web service Figure : End-to-End Configuration WS-Security along with some other standards like WS-Policy address these issues. OWASP App. Sec Europe 2006 5

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 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-Secure. Conversation describes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys OWASP App. Sec Europe 2006 7

Securing SOAP Messages using WS-Security Soap Message to send

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 6. Validate tokens Web Service Requester 3. Sending to 5. Enforcing WS-Policy Module Incorporating WS-Policy in SOAP 4. Sign/Encrypt & send SOAP message to web service 7. Receive response from Web Service Provider Figure: Typical message flow between web services using WS-Security OWASP App. Sec Europe 2006 9

< XML Rewriting Attacks OWASP App. Sec 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: Monday Sent: Tuesday From: Rahim To: Bank Sent: Wednesday Action: “Buy Charlie’s Action: “Pay Charlie $20” From: Rahim) book” (signed by To: Bookshop (signed by Rahim) Action: “Buy Jabbar’s book” (signed by Rahim) Online Book shop (Web Service) Rahim’s mobile Attacker may update and replay envelopes to confuse Book Shop OWASP App. Sec Europe 2006 11

A Signed SOAP Message Before. . . Message to bank’s web service says: “Transfer $1000 to karim, signed by Rahim”

and After an XML Rewriting Attack Charlie(Attacker) has intercepted and rewritten this message

Conceptual Solution and Proposed Technique < OWASP App. Sec 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 App. Sec 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 App. Sec 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 4. Sending SOAP message to SOAPAccount module 3. Sending to Policy Module Incorpor-ating WS-Policy in SOAP 8. Validate tokens Validating SOAP Account Info 5. Sending signed message with Adding SOAP Account Information 7. Enforcing WS-Policy 6. Received SOAP message Web Service Provider 9. Receive response from Web Service Figure: Message flow using new approach between web services OWASP App. Sec Europe 2006 17

A SOAP message after adding SOAP Account Message to bank’s web service says: ”Transfer

A SOAP request after an attempt to attack (Excerpt) Attacker has intercepted the message

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 App. Sec 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 jdk 1. 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. 80 GHz Processor and 512 MB RAM, running on Microsoft Windows XP Professional. OWASP App. Sec Europe 2006 21

Performance Evaluation-Two Considering the fact of being not enough for profiling Java code of using System. current. Time. Millis(), 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 App. Sec 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 App. Sec 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-Secure. Conversation 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 App. Sec Europe 2006 24