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 rewrit- ing 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 solu- tion 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

3. REWRITING ATTACK ON SOAP MESSAGES ( The XML rewriting attack is an exploitation of the XML ? tree by reordering the existing nodes or by wrapping nodes without altering the signature. This attack is possible only )+ because XML Signature standard provides context-free sig- nature. Indirect referencing of the signed element in the ? XML tree makes the signature to remain valid until the 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 ref- erenced 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 paredwiththeunder 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 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 element. deletes a message when the timestamp expires. An at- tacker 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 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. Header Body Id=’1’ 4.1 Context-Free Signature Security Security LoanRequest Definition 1. A Context-Free Signature(CFS)is a dig- ital signature, defined as a 2-tuple ,whereS = TimeStamp Signature Id=’T0' {δM }sA , δM = h(M) be the digest of message M, h() is a

one-way hash function, {δM }sA means δM is encrypted with SignedInfo Create a new security the secret key sA auserA, which can only be decrypted with header with role Cut this timestamp its conjugate public key pA. Without any loss of generality Reference Reference attribute value and copy it under a {} URI= #T0 URI= #1 « none » in our discussion, we will use to denote decryption as well. the new created security header Verification of the claim that message M is signed by A Figure 4: Case 3: Multiple Security Header Attack  Step 1: {{δM }sA }pA ⇒∃a message M which is signed by A. At this step we don’t know whether M  = M. processed by intermediaries (attribute none) and that  ←−  ⇒  if they can not process this tag they should not gen- Step 2: δM h(M); δM = δM M = M erate an error message (mustUnderstand=false). The attacker cut the old values of the timestamp under Therefore M is the message signed by A.Theclaimisver- this new created security header, and they add its own ified. Only after step 2 we can verify the claim completely. value for the timestamp element. The signature S and the signed message M are loosely coupled. The digest of the message is encrypted with the secret key of the signatory and that is the only logical rela- 4. CONTEXT FREE AND CONTEXT tionship between the signature and the message signed. This SENSITIVE DIGITAL SIGNATURES design decision of 2 tuple definition of digital signature using Let us revisit digital signature quickly in this section and public key and message digest is to avoid expensive encryp- define Context-Free and Context-Sensitive digital signatures. tion of the whole message. Instead of the whole message the Digital signature is for digital document as handwritten sig- fingureprint of the message, the digest, is encrypted. The nature is for paper document. It provides all the security strengths of CFS are strong proof of origin and the weakness requirements for digital documents as does the handwritten is the loose coupling between S and M. Security attacks are signature for paper documents. In our discussion we exclude encashing this weakness. XML rewriting attack is one of symmetric key signature, since our scope is limited to XML them. signatures in SOAP messages. So we are interested in public key based digital signature for this discussion. In Public-key 4.2 Context-Sensitive Signature cryptography each user has a pair of conjugate keys: a secret In this newly proposed signature we incorporate not only key and a public key. The secret key is known only to the the message but also the context of the message in the signa- user concerned and the public key is public, that is, known ture. In an evolving digital document, like SOAP message, to all. the context is time varying. The context incorporated into

55

a signature is basically the state of the dynamic context SC = {δC ,tC }sB , δM = h(M) be the digest of message M, t t at the time of signing. Therefore a temporal parameter is CM is the context of M at time t, δC = h(CM ), h() is a one- also incorporated in the proposed signature. Of course, it way hash function, tM is the time of signing the message, tC is considered as a best practice in security literature to in- is the time of signing the context. Here the mesage is signed corporate a timestamp, signifying the time of signing in the by the originator A and the context by another user B,not signature itself for use in security protocols but it is optional necessarily A. The verification process is similar to the gen- by definition in CFS. In CSS it is mandatory. eral CSS case. The advantage of this modified version is t Definition 2. The context CM of message M at at time that the proof of origin, the integrity of the message content t is the state of surrounding of M. The context defines the and the context are decoupled. As a result, the signed mes- position or the cordinate of a message and the message de- sage can freely migrate from context to context in different t rives its sematics from the context. Mapping of M to CM is documents without loosing the necessary semantics. 1:1 onto. By the definition above, a message is associated with a unique context. In a SOAP message, the context of a 5. FORMAL CONTEXT subtree may be defined by ancestors and siblings of the sub- The context of a subtree of a tree is the state of the grow- tree in the XML tree representation of the SOAP message ing tree at a particular time. It is defined by ancestors, [4]. A definition and a detail discussion of formal Context siblings and the degrees thereof. The composition of a par- using RTG is given in section 5. ticular node can be specified by a regular expression and the Definition 3. A Context-Sensitive Signature(CSS)is a t tree or a subtree can be specified by a regular tree grammar. digital signature, defined as a 3-tuple ,where Definition 5. A Regular Tree Grammar(RTG) is a 4- S = {δM ,δC ,t}sA , δM = h(M) be the digest of message t t tuple G = (N, T, S, P), where N is a finite set of nonter- M, CM is the context of M at time t, δC = h(CM ), h() is a minals, T is a finite set of terminals, S is the start symbol, one-way hash function, t is the time of signing the message. S ∈ N, P is the set of production rules of the form X ← aR, Verification of the claim that that message M in where X ∈ N, a ∈ T , and R is a regular expression over N; the context C is signed by A at time t. X is the left-hand side, aR is the right-hand side, and R is  called the content model of this production rule and it is a Step 1: {{δM ,δC ,t}sA }pA ⇒∃a message M which is in  Regular Expression [5]. A regular tree grammar defines acontextC is signed by A.Atthisstepwedon’tknow   a regular tree language. All the XML trees conforming to whether M = M and whether C is the context associated a given RTG forms the language specified by the RTG. A with M.    detailed study of RTG in XML Schema is available in [5]. Step 2: δM ←− h(M); δM = δM ⇒ M = M.Atthisstep Definition 6. A Regular Expression (RE) R is defined as we know that M is a message signed by A but we do not follows: know this instance of M is the one associated with the con- text at the time t which is signed by A. •∀w ∈ T is a RE.    Step 3: C ←− generateContext(M,t); δC = h(C );δC =  • (R) is a RE, ( ) is group operator. δC ⇒ M is the message associated with the context C which is signed by A at time t. • (R1,R2) is a RE, where R1, R2 are REs, R1 and R2 Therefore the claim is verified. Only after step 3 we can are in order. ’,’ is order operator. verify the claim completely. • (R1|R2) is a RE, where R1, R2 are REs and ’|’isor 4.3 Adaptive Context Sensitive Signature operator. The general CSS defined above is closely associated with • R[0, ∗] is a RE, R may occur 0 or more times. the context in which it is signed. For a migratory signed message, this general CSS will not serve the purpose. In • R[1, ∗] R may occur 1 or more times. certain situations it may be required that the signed mes- • R[n] R must occur exactly n times. sage to be taken out from the original document and added in a new document and thus gererate a new document. In Empty string λ is RE.InR[m, n], if m>nthe R[m, n]= such cases, the signed message becomes an orphan, loosing λ If m = n then R[m, m]=R[m]. The language specified its original context and adopted in a new context. This situ- by (x, y)isL(x, y)=(x, y), an ordered set. On the other ation is very much relevant to the SOAP Extensibility spec- hand, the language specified by (x|y)isL(x|y)={x, y},an ification [7]. For example, a client requests a travel agent for unordered set. Definition 7. A formal context is a 2-tuple t t t an itinerary, the travel agent composite Web service collects of a tree at time t,whereCM is the message t the price offers from the partner airline Web services, take context and SCM is the corresponding security context t out the signed offers from the corresponding SOAP messages Definition 8. A message context CM of a marked node and compose a new message with the offers and send it to [M] ∈ N of a tree at a particular time is defined by a set the client. The requirement in such migratory message is of well-formed productions of the RTG which are required that the signed message has to be valid in the new context. during derivation of the node. We need a special type of CSS to meet this requirement. We Definition 9. For each marked element node [M] ∈ N propose a special type as adaptive CSS with minor modifi- of a tree ∃ a corresponding marked node [B] ∈ N.The t cation of general CSS. The modification is basically a twin security context SCM at a time t is defined by a set of well- signature instead of one. formed productions of the RTG which are required during the Definition 4. An Adaptive Context-Sensitive Signature derivation of the marked node [B] (ACSS) is a digital signature, defined as a 4-tuple A context is said to to well-formed, if the following con- t ,whereSM = {δM ,tM }sA , ditions are satisfied:

56

• The partial grammar formed by the productions is un- Algorithm CSS Verification ambiguous. Input: A SOAP message with Context Sensitive Signature • for all productions of a formal context,the RE R, Output: Verification Result X ← aR, can have only absolute occurance indica- 1: Select the message(subtree) M’ to be verified tor, that is of the form R[n]. No occurance indicator 2: Cannonicalize M’ implies n=1. 3: Decrypt CSS with the public key of the user 4: if Decryption fails then • The M to be signed is to be marked as [M]inthe 5: ”Signature is invalid”, Stop R of the production where it it appears. Marked [M] 6: end if can occur exactly once(n=1)and appear exactly in one 7: Generate new digests of stored C and M’ and only one production and this production is the one 8: if the new digest of C is equal to the one available is which is used in the last step of derivation of M. CSS then • If the derivation path includes a node Y,Y ∈ N which 9: if M’ is derivable from C and the derivation path is is the ith occurrance of Y [n],n > 1inR then Y [n]is from S to [M] then replaced by an equivalent RE Y [1,i− 1],Y,Y[i +1,n]. 10: if the new digest of M’ is equal to the digest in CSS then In the well-formedness conditions of a context, unambigu- 11: ”Signature is valid” ous grammar ensures that there is one and only one deriva- 12: else tion tree and the occurance indicator n =1 for all the non- ”Content of the message is tempered: Signature terminals appearing in the derivation path ensures that there is invalid” exists only one derivation path upto M. The genesis of 13: end if replacement of an RE containg multiple occurance by an 14: else equivalent one is to specify explicitly which of the multiple ”Message is out of Context(Rewriting attack!)”, identical nodes is used in the derivation and to segrigate it ”signature is invalid” out. Remaining identical siblings will be the parts of its 15: end if context. 16: else ”Context is tempered: Signature is invalid” 6. SIGNATURE GENERATION AND 17: end if VERIFICATION Figure 6: Algorithm: CSS Verification In this section we describe the algorithms to generate and to verify CSS. 7. ANALYSIS OF THE SOLUTION Algorithm CSS Generation In this section we generate the formal context of the cases Input: A SOAP message presented in section 3 and verify them using the algorithms Output: A SOAP message with Context Sensitive Signa- discussed previously. ture Case 1: 1: Select the node(subtree) M to be signed In Figure 2(a) the element signed is the Body, its message t 2: Cannonicalize M context CM is expressed by the following production rule: 3: Generate Context C Envelope ← (Header,[Body]) t 4: Generate productions of RTG required to derive M The corresponding security context SCM is defined by the 5: Segregate and mark [M] in the production it appears following set of productions: 6: Generate the digests of C and M Envelope ← (Header,Body) 7: Generate the CSS on the digests in STEP 4 using the Header ← (Security,ReplyTo) secret key of the user Security ← (Signature) 8: Store C and CSS in signature info Signature ← (SignatureInfo) SignatureInfo ← (Reference, [Reference]) : This is the Figure 5: Algorithm: CSS Generation corresping element [B] of a marked node [M] When the rewritten message in Figure 2(b) is received veri- Since the state of the context at the time of signing is fication algorithm describe in Figure 6 will be triggered: In generated and stored persistantly for verification, the times- step 1, the message M’ is selected with regards to the Ref- tamps included in the definition of CSS are not used in these erence element. M’ is now located under the BogusHeader. algorithm. Our intension is to avoid the regenarion of the Steps 2 to 8 are executed successfully, in step 9 the actual context’s state during verification. The tradeoff is the stor- derivation path generated using the stored message context age of the context. However, if timestamps are used in every is: Envelope ⇒ [Body] but the message under verification element added to an XML tree as attributes than such stor- is not in this derivation path and hence out of context, a age of the context can be avoided. But again the tradeoff rewriting attack occured. will be the computaional time to regenerate of the context’s Case 2: state from a time-varying tree, which itself may be complex. It is a redirection attack, the change occured in the signed However, alternative algorithms can be designed in this di- ReplyTo element. For the message prior to attack the cor- t rection as well and that study will be interesting. ACSS responding message is context CM : is an extension of CSS hence the above algorithms can be Evenlope ← (Header,Body) extended to take care of the adaptivity. Header ← (Security,[ReplyT o])

57

t We generate the corresponding security context SCM that not address all type of XML rewriting attacks [1, 3]. In has the following production: [3] the authors demonstrate that the state of the art solu- Envelope ← (Header,Body) tions are not addressing all type of rewriting attacks and Header ← (Security,ReplyTo) present some ideas to fix the issue but do not present a com- Security ← (Signature) plete working solution. A similar work is done in [1] where Signature ← (SignatureInfo) the authors propose to take into account new characteristics SignatureInfo ← (Reference, [Reference]) ← this is the of SOAP message such as the depth information and parent corresping element [B] of a marked node [M] elements of the signed node as well as a way to uniquely When the verification occurs: In step 1, the message M’ is identify the parent elements. While this approach provides selected with regards to the Reference element. M’ is now a significant improvement, it does not present a complete so- located under the BogusHeader. Steps 2 to 8 are executed lution. In [2] the author present a tool called TulaFale. This successfully, in step 9 the actual derivation path generated tool has been developed under the umbrella of the SAMOA using the stored message context is: Envelope ⇒ Header ⇒ project (Formal tools for securing Web services) which aims [ReplyT o] but the message under verification is not in this at providing a tool suite to enhance security of web services, derivation path and hence out of context, an attack occured. and to reason about web service security at an abstract level. Case 3: TulaFale is a scripting language that formally specifies web This attack, is an exploitation of Multiple Security Header service security protocols and analyze their security vulner- in the same SOAP message. This message has two signed ability. It uses applied pi calculus to specify the interaction element, the Body and the Timestamp. Therefore there among concurrent processes. TulaFale extended pi calculus will be two context. Before we relocate the timestamp, the to include XML syntax and symbolic cryptographic opera- message context for the Body is defined by the following tions for specifying the SOAP message exchange. For spec- productions: ifying the construction and verification of SOAP messages, Envelope ← (Header,[Body]) The corresponding security TulaFale uses Prolog-style predicate. The different security t context SCM is defined similarly by the following produc- goals of a SOAP security specification are specified using as- tions: sertions. While TulFale uses formal methods to analyze web Envelope ← (Header,Body) service security, it does not provide a solution to the XML Header ← (Security) rewriting attack. Security ← (Signature,TimeStamp) Signature ← (SignedInfo) 9. CONCLUSION AND FUTURE WORKS ← ← SignedInfo (Reference, [Reference]) this is the cor- In this paper we proposed a formal solution to the XML resping element [B] of a marked node [M] rewriting attack on secure SOAP messages. We defined the Likewise the Timestamp message context is the defined by state of the art signature as a two tuple Context-Free Sig- the following productions: nature. Our solution is a Context-Sensitive Signature, it ← Envelope (Header,Body) captures the context of the signed element at the time of ← Header (Security) signing and incorporate the signed message context in the ← Security (Signature,[TimeStamp]) signature element making any change detected. We provide Respectivly the security context of the TimeStamp is de- algorithms to generate the context and to verify it. Our so- fined as follows: lution is the first formal solution to rewriting attacks and ← Envelope (Header,Body) provides countermeasures for all known forms of rewriting ← Header (Security) attacks available in the literature today[4, 1, 6, 3]. But this ← Security (Signature,TimeStamp) does not come free. The trade off is that the context is to ← Signature (SignedInfo) be generated and stored in the reference element of the sig- ← ← SignedInfo ([Reference], Reference) this is the cor- nature in header section before signing the message. In our resping element [B] of a marked node [M] future work in this direction we are trying to study the com- When the receiver verify this message: putational overhead of the proposed solution with regards to Since we focus on the TimeStamp attack we skip the ver- existing solutions [6, 1] and explore the limitations, if any, ification of the Body. Similarly, it reaches step 9 where it of the present solution of XML rewriting attacks as well detects that the derivation path is not the valid one. The as integration of the present formalism into existing formal attack is detected. framework to analyze web service security. 8. RELATED WORK 10. REFERENCES In [4] the importance of context is discussed, serveral con- [1] A. Benameur, F. Abdul Kadir, and S. Fenet. XML text where identified: ancestry, optional element, sibling or- Rewriting Attacks: Existing Solutions and their der etc. Moreover the issue of migratory signature is also Limitations. In IADIS Applied Computing 2008.IADIS discussed but no solution is provided. In [6] the authors Press, Apr. 2008. proposed an inline approach that takes into account infor- [2]K.Bhargavan,C.Fournet,A.D.Gordon,and mation about the structure of the SOAP message by adding R. Pucella. Tulafale: A security tool for web services. In a new header element called SOAP Account. This SOAP FMCOS03:ˇ Second International Symposium on Formal Account element must be signed by the creator using its Methods for Components and Objects. LNCS 2003. X.509 certificate. Each successive SOAP node must sign [3] S. Gajek, L. Liao, and J. Schwenk. Breaking and fixing its own SOAP account concatenated with the signature of the inline approach. In SWS ’07: Proceedings of the the previous node. While this approach can prevent certain 2007 ACM workshop on Secure web services, pages XML rewriting attack it has been demonstrated that it can 37–43, New York, NY, USA, 2007. ACM.

58

[4] M. McIntosh and P. Austel. Xml signature element [6] M. A. Rahaman, A. Schaad, and M. Rits. Towards wrapping attacks and countermeasures. In SWS ’05: secure soap message exchange in a soa. In SWS ’06: Proceedings of the 2005 workshop on Secure web Proceedings of the 3rd ACM workshop on Secure web services, pages 20–27, New York, NY, USA, 2005. services, pages 77–84, New York, NY, USA, 2006. ACM. ACM. [5] M. Murata, D. Lee, M. Mani, and K. Kawaguchi. [7] Simple object access protocol 1.1, 2000. Taxonomy of languages using formal http://www.w3.org/TR/soap/. language theory. ACM Trans. Interet Technol., [8] Web service security, 2006. 5(4):660–704, 2005. http://www.oasis-open.org/committees/wss/. [9] XML-signature syntax and processing, 2002. http://www.w3.org/TR/xmldsig-core/.

59