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

[Anthony Nadalin <drsecure@us.ibm.com>]

OK I have added this to the draft I posed last night. Seems I had a problem with the date as the files say Monday June 14th but should have been Monday June 13th

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Michael McIntosh/Watson/IBM@IBMUS

Michael McIntosh/Watson/IBM@IBMUS

06/14/2005 02:08 AM

To	Anthony Nadalin/Austin/IBM@IBMUS
cc	wss@lists.oasis-open.org
Subject	Re: [wss] Issue 399: Proposed Security Consideration Text

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 
>


---------------------------------------------------------------------
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