Recently discover WSS security threat

["Hal Lockhart" <hlockhar@bea.com>]

The following issue is being discussed in the WS-I BSP WG. I think members of this TC will want to know about it. The TC may want to adress it in some way under security considerations.

Assume a receiver that has a policy that specifies acceptable trust roots, etc. Assume that the policy states that the SOAP Body of any request received must be signed. Further assume that there is some kind of SOAP header, we will call the foo header, which is optional but specifies important processing to be done on the message by the receiver. The receiver's policy says that if the foo header is present it must be signed. If the foo header is present, this receiver can (and will) correctly process it.

The receiver has an implementation which consists of (at least) a security layer and an application layer. When a message is received, the security layer verifies signatures, performs decryption, checks passwords, etc. It may enforce some security-related policies as well, but for example, it is not responsible for the SOAP MustUnderstand logic. Once the security layer is finished processing a message it passes the message (with the decrypted data) on to the application. It also passes along information relating to the processing it did, for example, what parts of the message were signed with what tokens, what was encrypted and so forth.

Now let us talk about attacks.

1. If the sender is so foolish to sign something, e.g. the foo header, and put nothing else under that Signature, there is a simple attack. (Assume the body is signed under a different Signature.) A MITM attacker can simply remove the Signature and the foo header. The receiver cannot tell they were ever present.

2. So to prevent attack #1, the sender uses two <ds:References> in a single <ds:Signature> to sign the Body and the foo header. This is where the Plain Brown Wrapper attack can happen. A MITM attacker wraps the foo header in some made up header, let's call it the bar header.

Under the policies we have assumed above, the security layer will verify the signature as being correct, because the text has not been altered, only moved to a new spot in the message. The body is signed, so that policy is satisfied. The foo header is not seen, but that is allowed. 

The bar header is seen and not understood, but since it is marked MU=F, the receiver is allowed to ignore it. Presumably the application does not dig thru unknown SOAP headers looking for elements it recognizes. Anyway, a foo element in a bar header may mean something different from a foo header, since the app does not know what a bar header is supposed to look like.

------

Now there are some ways to fix this which I think would be incorrect in that they would result in reduced flexibility and brittle applications which would break every time the network changes. These include:

Treat presence of foo header as mandatory.

Reject any message where too much is signed.

Reject any message with unknown stuff in it.

Specify the ds:Reference in such a way that intermediaries cannot add SOAP headers.

----

I am not completely sure what the best way to counter this is. One approach is for the receiver to take special care. For example the receiver might follow a rule like:  If you receive something with a signature over something that your policy requires to be signed, you need to make sure you can process EVERYTHING under the same signature.

Another approach that has been mentioned is for the sender to use some kind of Xpath expression in the reference list instead of an Id Attribute. I am concerned that this might prevent reasonable intermediary actions, but I would have to see specific Xpath expressions proposed before making a judgement.

Hal