RE: [wss] Recently discover WSS security threat

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

] > Consider I have a header that looks like this:
] >
] > <my:header>
] >   <my:integer>32</my:integer>
] > </my:header>
] >
] > Now suppose I reference the envelope, run an XPath as you described
to
] > select just my:header and all its descendents, and then run a custom
] > transform to increment all integers by 1.  The signed data looks
like
] > this:
] >
] > Reference 1:
] > <my:header>
] >   <my:integer>33</my:integer>
] > </my:header>
] > Reference 2:
] > <soap:Body>...<soap:Body>
] >
] > What does the application see as the authentic data?  32 or 33?
] > According to the DSIG spec, the answer is 33.
] 
] I disagree. The DSIG specification discribes how to create and verify
] signatures. It does not discribe what gets passed to applications.

It says, "Just as a user should only sign what he or she "sees," persons
and automated mechanism that trust the validity of a transformed
document on the basis of a valid signature should operate over the data
that was transformed (including canonicalization) and signed, not the
original pre-transformed data."

33 is the data that was transformed and signed.
32 is the original pre-transformed data.

I think it is very clear that receivers in this case should operate on
33.

] > But now let me ask you,
] > if a receiver follows the processing model you described, where does
it
] > determine that the 33 resides in the message?
] 
] I don't think most people would use transforms specified for signature
] verification to obfuscate data.

I wasn't trying to obfuscate data, just give an example of a transform
that is semantically important.

] > The signed data looks like this:
] >
] > Reference 1:
] > <soap:Envelope>
] >   <soap:Header>
] >     <my:header>
] >       <my:integer>33</my:integer>
] >     </my:header>
] >   </soap:Header>
] >   <soap:Body>...</soap:Body>
] > </soap:Envelope>
] >
] > I see no more room for ambiguity.  Clearly the authentic data is 33
and
] > its relationship to the soap:Body is specified by the soap:Envelope.
] 
] So using your alternative if there where multiple References in the
] signature
] the application would receive a complete SOAP Envelope for each?

If each reference referred to the SOAP Envelope, then, yes, the
application would receive a complete SOAP Envelope for each.  However, I
see little reason why a sender would actually use multiple Envelope
References in my case.  Rather they would just make sure their one
Envelope Reference included everything from the Envelope they wanted to
sign.

] I think your solution provides the same level of protection as the
simple
] XPath.
] However, your solution requires a more complex XPath expression and is
] therefore
] harder to use and probably less efficient.

Looking at the XPath expressions for each approach, I don't see any
difference in complexity.  If you see one, perhaps you can give examples
that we could use to quantify the difference?

&Thomas.