OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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
Inactive hide details for Michael McIntosh/Watson/IBM@IBMUSMichael McIntosh/Watson/IBM@IBMUS


          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 


GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]