Re: [wss] Issue 399: Proposed Security Consideration Text

[Michael McIntosh <mikemci@us.ibm.com>]

That sounds like a good place for it.

Anthony Nadalin/Austin/IBM wrote on 06/13/2005 05:13:29 PM:

> So to be clear you are suggesting that this go in the security 
> considerations section under 13.2 Additional Considerations as a new
> sub section titled "Removal and modification of XML elements" ?
> 
> 
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> 
> Michael McIntosh/Watson/IBM@IBMUS 
> 06/13/2005 01:27 PM
> 
> To
> 
> <wss@lists.oasis-open.org>
> 
> cc
> 
> Subject
> 
> [wss] Issue 399: Proposed Security Consideration Text
> 
> This text addresses the comments by Hal and Thomas:
> 
> XML Signatures using Shorthand XPointer References (AKA IDREF) protect 
> against the removal and modification of XML elements; but do not protect 

> the location of the element within the XML Document.
> 
> Whether or not this is a security vulnerability depends on whether the 
> location of the signed data within its surrounding context has any 
> semantic import. This consideration applies to data carried in the SOAP 
> Body or the Header. 
> 
> Of particular concern is the ability to relocate signed data into a SOAP 

> Header block which is unknown to the receiver and marked 
> mustUnderstand="false". This could have the effect of causing the 
receiver 
> to ignore signed data which the sender expected would either be 
processed 
> or result in the generation of a MustUnderstand fault.
> 
> A similar exploit would involve relocating signed data into a SOAP 
Header 
> block targeted to a S11:actor or S12:role other than that which the 
sender 
> intended, and which the receiver will not process.
> 
> While these attacks could apply to any portion of the message, their 
> effects are most pernicious with SOAP header elements which may not 
always 
> be present, but must be processed whenever they appear.
> 
> In the general case of XML Documents and Signatures, this issue may be 
> resolved by signing the entire XML Document and/or strict XML Schema 
> specification and enforcement. However, because elements of the SOAP 
> message, particularly header elements, may be legitimately modified by 
> SOAP intermediaries, this approach is usually not appropriate. It is 
> RECOMMENDED that applications signing any part of the SOAP body sign the 

> entire body.
> 
> Alternatives countermeasures include (but are not limited to):
>         References using XPath transforms with Absolute Path 
expressions,
>         A Reference using an XPath transform to include any significant 
> location-dependent elements and exclude any elements that might 
> legitimately be removed, added, or altered by intermediaries,
>         Using only References to elements with location-independent 
> semantics,
>         Strict policy specification and enforcement regarding which 
> message parts are to be signed. For example:
>                 Requiring that the entire SOAP Body and all children of 
> SOAP Header be signed,
>                 Requiring that SOAP header elements which are marked 
> MustUnderstand="false" and have signed descendents MUST include the 
> MustUnderstand attribute under the signature.
> 
> Thanks,
> Mike
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>