Issue 399: Proposed Security Consideration Text

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

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