A Formal Solution to Rewriting Attacks on SOAP Messages

A Formal Solution to Rewriting Attacks on SOAP Messages Smriti Kumar Sinha, Azzedine Benameur SAP Research, Security&Trust Avenue du Docteur Maurice Donat 805 MOUGINS, 06250, France {smriti.kumar.sinha, azzedine.benameur}@sap.com ABSTRACT these messages are prone to attacks that can lead to sev- In Service Oriented Architecture Web Services, communi- eral consequences, such as, unauthorized access, disclosure cation among services is banking on XML-Based messages, of information, identity theft etc. These attacks are basi- called SOAP messages. These messages are prone to at- cally on-the-fly modifications of SOAP messages, referred as tacks that are classified in literature as XML rewriting at- XML rewriting attacks[4, 1]. Providing a solution to XML tacks. Since rewriting is a formal mechanism used in for- rewriting attack on SOAP messages is a vital challenge of mal language theory, and the rewriting attack problem is Web service security. The attacks are framed on the weak- designed under the framework of formal language theory, nesses of XML signature. SOAP is the message strucuture the solution also lies under the same framework. In this specification used for exchanging messages among Web ser- paper we propose a formal solution to XML rewriting at- vices in SOA environment. SOAP uses XML signature [9] tacks on SOAP messages using regular tree grammar. To as a security mechanism to address proof of origin and con- the best of our knowledge this is the first formal solution to tent integrity issues of XML payload. It also allows to sign this problem. We define current XML signatures used in a not only the whole XML payload but also parts of it. This SOAP message as context-free signature. The formal solu- opens up the flush door to security attacks and makes secure tion proposed here is a context-sensitive XML signature. To SOAP message exchange vulnerable. Different solutions are address the additional requirements of SOAP extensibility proposed in the literature to address this problem[6, 1, 3]. model, where a SOAP message can pass through several in- These solutions are mainly from a data stucture point of termediaries before reaching the final receiver, an adaptive view. The motivation behind this approach is obviously the variant of context-sensitive signature is also proposed. The tree representation of a SOAP message. solution addresses different forms of XML rewriting attacks. 1.1 Motivation An analysis of the solution is also given in the paper. Our motivation is from the formal point of view. Rewrit- ing is a formal mechanism used in formal language theory. Categories and Subject Descriptors Since the problem is designed under the framework of for- D.2.11 [Software Engineering]; D.4.6 [Security and Pro- mal language theory, the solution of the problem also lies tection] under the same framework. This is the main motivating force behind this proposition. This formalism can then be integrated in a formal analysis framework to verify security General Terms properties of web service security protocols. Security Design Verification 1.2 Contributions Keywords In this paper we propose a formal solution to XML rewriting attack on SOAP messages using Regular Tree Gram- Regular Tree Grammar, Formal Methods, XML Rewriting mar(RTG). We define XML signatures used in SOAP mes- Attack, Context-Sensitive Signature, SOAP, Security sages as Context-Free Signatures (CFS). The formal solution proposed here is a Context-Sensitive Signature (CSS). 1. INTRODUCTION This solution addresses all forms of XML rewriting attacks In SOA Web Services, communications are made through on SOAP messages. To the best of our knowledge this is XML-Based messages, called SOAP messages. Unfortunately, the first formal solution to this problem. An analysis of the solution is also provided. The remaining sections of the paper are organized as fol- lows. In section 2 we discuss XML signature and its weak- Permission to make digital or hard copies of all or part of this work for ness, followed by section 3 describing the rewriting attacks personal or classroom use is granted without fee provided that copies are on SOAP messages. In section 4 we formally define the state not made or distributed for profit or commercial advantage and that copies of the art XML signature as a Context-Free signature and bear this notice and the full citation on the first page. To copy otherwise, to propose our solution namely a Context-Sensitive signature. republish, to post on servers or to redistribute to lists, requires prior specific To address the SOAP extensibility requirements which al- permission and/or a fee. SWS’08, October 31, 2008, Fairfax, Virginia, USA. lows a message to be transformed by multiple actors, we Copyright 2008 ACM 978-1-60558-292-4/08/10 ...$5.00. define an adaptive context sensitive signature. In section 53 <Signature Id?> 3. REWRITING ATTACK ON SOAP <SignedInfo> <CanonicalizationMethod/> MESSAGES <SignatureMethod /> (<Reference URI?> The XML rewriting attack is an exploitation of the XML <Transforms/>? tree by reordering the existing nodes or by wrapping nodes <DigestMethod> <DigestValue> without altering the signature. This attack is possible only </Reference>)+ because XML Signature standard provides context-free sig- </SignedInfo> <SignatureValue> nature. Indirect referencing of the signed element in the <KeyInfo>? XML tree makes the signature to remain valid until the <Object Id ?> </Signature> equality of the values of data referenced by the @URI in < ReferenceURI? > element with the one of @ID of the XML payload holds. Based on this weakness of the XML Figure 1: XML Signature Structure Signature specification, we identified three attacks that can be applied to SOAP message[7]. 5 we define the formal context using Regular Tree Gram- • Replay Attack: mar, followed by the corresponding generation and verifica- This attack is depicted in Figure 2. On the left side tion algorithms in section 6. The proposed solution is then is a valid message with a signed Body. On the right analyzed in section 7 in the light of the rewriting attacks side of the figure the attacker wraps the existing body discussed in section 3. Some recent works to counter the into a bogus header, making this Body meaningless attacks are critically reviewed in section 8. Finally we con- for the receiver, and create it’s own element namely clude the discussion with some of our future work in this ”newBody”. According to SOAP specification [7] the direction in section 9. ”newBody” element is not requiered to have an identi- fier ”Id”. This signature is still valid because the referenced element ”#1” is still present and not changed. 2. XML SIGNATURE • SOAP messages are carrying information from one web Redirection Attack: service to another. In this context security plays an im- In this scenario the attacker uses the same method portant role therefore a Web Service Security specification as above. He wraps the ”Reply To” element under emerged [8]. To ensure authenticity as well as non-repudiation a bogus header, create its own ”Reply To” element. a signature mechanism is provided based on the XML Digi- When the receiver of this message process this message tal Signature specification[9]. The latter specify that a mes- the signature is valid, and the service response is sent sage may contain one or more signed elements. This sig- to the ”NewAddress” the attacker has inserted in the nature schema depicted in Figure 1 is a 2-tuple signature, message. where the signed element is referenced by its URI under the < ReferenceURI? > element. Envelope The weakness of the XML Signature lies within its verifi- Header cation. The verification process is done through two succes- Body sive steps: Security Reply To BOGUSHEADER LoanRequest • Reference Validation: The < SignedInfo > element is Reply To: Signature NewAddress canonicalized using the specificed Id#1 < CanonicalizationMethod >,thenforeach < Reference > element, the referenced data object SignedInfo Address is retrieved and the digest value is computed and com- Reference Reference paredwiththe<DigestValue>under the URI= #1 < Reference > element. If this reference validation succeed then the signature validation is executed, oth- Figure 3: Case 2: Redictection Attack erwise it generates an error message. • Signature validation: The keying information is re- • Multiple Security Header attack: trieved under the <KeyInfo>element, possibly To reduce the possibility of mounting replay attacks, from an external source, and the signature method WS-Security standard [8] offers the possibility to add used is defined under the < SignatureMethod > ele- a timestamp element. This timestamp element can ment. These two element are then used to validate the be used by the server to manage its cache, the server <SignedValue>element. deletes a message when the timestamp expires. An attacker can exploit this to create successful attacks, see XML Signature allows non-contiguous object of an XML Figure 4. The WS-Security specification allows more dataset to be signed separately. The signed object is ref- than one security header to co-exist within a soap mes- erencedbyanindirection(URI)fromthe< Reference > sage but two security headers can not have the same element of the signature. This indirect referencing gives no role attribute value. The attacker creates a new se- information about the actual location of the signed element. curity header with the role attribute ”none” and with This leads to rewriting attacks, where an object can be re- ”mustUnderstand=false” the effect of these attributes located and the signature still remains valid. is that this new created security header will not be 54 Envelope Envelope Header Header Body Id= ‘1’ newBody Security Reply To Security Reply To BOGUSHEADER LoanRequest ModifiedRequest Signature Address Signature Address Body Id=’1’ SignedInfo SignedInfo LoanRequest Reference Reference Reference Reference URI= #1 URI= #1 (a) SOAP Message with a signed Body (b) Rewriting Attack with a new Body Figure 2: Case 1: Replay Attack Envelope A message encrypted with the secret key can be decrypted with the conjugate public key or vice-versa.

Load more