View source for XML Signature Wrapping - Optional Element

=Attack description=
In other scenarios the signed data is contained within the SOAP Header and is optional. A typical example is the <ReplyTo> element, that specifies where to send the reply to. 
When comparing this scenario to the previous example the [[XML Signature Wrapping - Simple Context]] attack, the problem is not the positioning of the signed data within SOAP Header. The problem is that the signed data is optional. 
This scenario is not covered by the previous example.

'''Note:''' Make sure to read the prerequisites of the attack to understand in what scenarios this attack works. 


=Attack subtypes=
There are no attack subtypes for this attack.


=Prerequisites for attack=
In order for this attack to work the attacker has to have knowledge about the following things:
#'''Attacker knows endpoint of web service.''' otherwise he is not able to reach the web service. 
#'''Attacker knows that the web web service processes the security header and the "signature" element.''' If the web service doesn't "expect" a signed part, it just discards the signature and the attack doesn't work.
#'''Attacker can reach endpoint from its location.''' Access to the attacked web service is required. If the web service is only available to users within a certain network of a company, this attack is limited.
#'''Signed data is an optional element outside of the security Header'''


=Graphical representation of attack=

[[Image:AttackedComponent_Signature.png]]

*Red = attacked web service component<br>
*Black = location of attacker<br>
*Blue = web service component not directly involved in attack.<br>





=Attack example=
All examples taken from[http://portal.acm.org/citation.cfm?id=1103026&coll=Portal&dl=ACM&CFID=68374631&CFTOKEN=27107299].
Listing 1 shows a valid unmodified SOAP message. This time the signed part is the <wsa:ReplyTo> element.
The <wsa:ReplyTo> element specifies where the reply is sent. In this example we assume that the element is optional.

<source lang=xml>

<soap:Envelope ...>
  <soap:Header>
   <wsse:Security>
     ...
     <ds:Signature>
       <ds:SignedInfo>
         ...
         <ds:Reference URI="#theBody">
           ...
         </ds:Reference>
         <ds:Reference URI="#theReplyTo">
           ...
         </ds:Reference>
       </ds:SignedInfo>
         ...
       </ds:Signature>
     </wsse:Security>
     <wsa:ReplyTo wsu:Id=”theReplyTo>
       <wsa:Address>http://good.com/</wsa:Address>
     </wsa:ReplyTo>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol=”IBM”/>
  </soap:Body>
</soap:Envelope>


</source>
Listing 1: Unmodified SOAP message with signature



Listing 2 shows the same example. However a change was made: 
The <wsa:ReplyTo> element got placed in a <wrapper> element that is positioned below the <wsse:security> element. Furthermore the <wrapper> element got assigned the following attributes:
* soap:mustUnderstand="0" - That means that this element is optional [http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383500]
* soap:role=".../none"    - That means that the the SOAP node (application logic) should not process this header element[http://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.webservices.doc/concepts/soap/dfhws_header.html].
The above attribute settings cause the <wsa:ReplyTo> to be completely ignored by the application logic later on.

<source lang=xml>


<soap:Envelope ...>
  <soap:Header>
   <wsse:Security>
     ...
     <ds:Signature>
       <ds:SignedInfo>
         ...
         <ds:Reference URI="#theBody">
           ...
         </ds:Reference>
         <ds:Reference URI="#theReplyTo">
           ...
         </ds:Reference>
       </ds:SignedInfo>
         ...
       </ds:Signature>
     </wsse:Security>
     <Wrapper
       soap:mustUnderstand="0"
       soap:role=".../none" >
     <wsa:ReplyTo wsu:Id=”theReplyTo>
       <wsa:Address>http://good.com/</wsa:Address>
     </wsa:ReplyTo>
     </Wrapper>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol=”IBM”/>
  </soap:Body>
</soap:Envelope>

</source>
Listing 2: Maliciously modified SOAP message with signature



What happens when the SOAP Message gets processed:
#The XML Signature verification algorithm starts looking for the element with the id "theReplyTo", as stated in the <Reference> element. 
#Eventually it will find the <wsa:ReplyTo> Element wrapped within the <wrapper> element. 
#Signature verification will be performed on the <wsa:ReplyTo> within the <wrapper> element. Signature verification will be positive, since it contains the unmodified <wsa:ReplyTo> that got signed by the sender. 
#The SOAP Body and entire children that are understood get passed to the application logic. The <wrapper> element doesn't get passed over to the application logic. Therefore the application logic behaves as if the <wsa:ReplyTo> element is not present and replies to the original sender of the message. 
 

=Attack mitigation / countermeasures=
The attack worked because of two major flaws: 
* The position of the signed data was not fixed within the XML document. Horizontal and vertical movement within the XML document was possible without invalidating the signature.
*XML Signature Verification and processing by the application logic are two different processes that validate/process data according to their own set of rules.


The strategy to defend against this scenario, are as follows: 
* Define a strict receiver side security policy:
**the element specified by /soap:Envelope/soap:Body must be referenced from a signature "A" using WSS with XML Signature, and
**if present, any element matching /soap:Envelope/soap:Header/wsa:ReplyTo must be referenced via an absolute XPath path expression having a signature "A" using WSS with XML Signature, and
**the signature "A" verification key must be provided by an X.509v3 certificate issued by one of a set of trusted Certified Authorities (CA).
* Define a sender side specification of a security policy. <br> Apply an XPath expression within the <Reference> element of the XML Signature that points to the signed data. <br>Listing 3 gives an example for such a transform. <source lang=xml>


<soap:Envelope ...>
  <soap:Header>
   <wsse:Security>
     ...
     <ds:Signature>
       <ds:SignedInfo>
         ...
         <ds:Reference URI="#theBody">
           ...
         </ds:Reference>
         <ds:Reference URI="">
           <ds:Transforms>
             <ds:Transform Algorithm=".../REC-xpath-19991116">
               <ds:XPath ...>
                 /soap:Envelope/soap:Header/wsa:ReplyTo
               </ds:XPath>
             </ds:Transform>
             <ds:Transform Algorithm=".../xml-exc-c14n#"/>
           </ds:Transforms>
           ...
         </ds:Reference>
       </ds:SignedInfo>
         ...
       </ds:Signature>
     </wsse:Security>
     <wsa:ReplyTo wsu:Id=”theReplyTo>
       <wsa:Address>http://good.com/</wsa:Address>
     </wsa:ReplyTo>
  </soap:Header>
  <soap:Body wsu:Id="theBody">
    <getQuote Symbol=”IBM”/>
  </soap:Body>
</soap:Envelope>

</source> Listing 3: SOAP message with XPath expression in <Reference> element

'''NOTE:''' This countermeasures only apply to this specific attack scenario. Make sure that your scenario matches the scenario described above. 
Otherwise your application might be vulnerable.


=Attack categorisation=
==Categorisation by violated security objective==
The attack aims at exhausting the system resources, therefore it violates the security objective Availability.
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Integrity]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective]]
*[[:Category:Attack_Categorisation_By_Violated_Security_Objective_Integrity]]
*[[:Category:Attack_Categorisation_By_Violated_Security_Objective]]


==Categorisation by number of involved parties==
[[Category:Attack_Categorisation_By_Number_Of_Involved_Parties:1_-_0_-_1]]
[[Category:Attack_Categorisation_By_Number_Of_Involved_Parties]]

*[[:Category:Attack_Categorisation_By_Number_Of_Involved_Parties:1_-_0_-_1]]
*[[:Category:Attack_Categorisation_By_Number_Of_Involved_Parties]]


==Categorisation by attacked component in web service architecture==
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component]]

*[[:Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
*[[:Category:Attack_Categorisation_By_Attacked_Web_Service_Component]]


==Categorisation by attack spreading==
[[Category:Attack_Categorisation_By_Attack_Spreading]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]

*[[:Category:Attack_Categorisation_By_Attack_Spreading]]
*[[:Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]




=References=
# Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon and Greg O’Shea. An Advisor for Web Services Security Policies. CCS Workshop on Secure Web Services, 2005. http://research.microsoft.com/en-us/um/people/fournet/papers/an-advisor-for-web-services-security-policies-sws05.pdf
# Michael McIntosh and Paula Austel. Xml signature wrapping attacks and countermeasures. Technical report, IBM Research, Hawthorne, New York, 10532, 2005.
# Mohammad Ashiqur Rahaman, Maarten Rits, and Andreas Schaad. An inline approach for secure soap requests and early validation, 2005.
# Sebastian Gajek, Lijun Liao, and Jörg Schwenk. Breaking and fixing the inline approach. Technical report, Horst G ̈rtz Institute for IT-Security, 44780 Bochum, Germany, 2007.
# Nils Gruschka and Luigi Lo Iacono. Vulnerable Cloud: SOAP Message Security Validation Revisited. In Proceedings of the IEEE International Conference on Web Services, 2009. http://cs.uccs.edu/~gsc/pub/phd/chow/doc/vulnerableCloud2009.pdf
# Frederick Hirsch and Pratik Datta. Xml signature best practices. http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/, 2010. Accessed 01 July 2010.
# Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, Luigi Lo Iacono. All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces. In Proceedings of the ACM Cloud Computing Security Workshop (CCSW), 2011. https://www.nds.rub.de/research/publications/amazon-hacking/
# Meiko Jensen, Christopher Meyer, Juraj Somorovsky, Jörg Schwenk. On the Effectiveness of XML Schema Validation for Countering XML Signature Wrapping Attacks. In Proceedings of the ACM Cloud Computing Security Workshop (CCSW), 2011. https://www.nds.rub.de/research/publications/OnTheEffectivenessOfXMLSchemaValidation/
# Juraj Somorovsky. On the Insecurity of XML Security. PhD thesis supervised by Jörg Schwenk and Kenny Paterson, Ruhr University Bochum. https://www.nds.rub.de/research/publications/xmlinsecurity/