[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Recently discover WSS security threat
Here is the specific XPath expression I think you are looking for: <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <dsig:SignedInfo> ... <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2"> <dsig-xpath:XPath Filter="subtract"> /soap:Envelope/soap:Header/* </dsig-xpath:XPath> <dsig-xpath:XPath Filter="union"> id("123") </dsig-xpath:XPath> </dsig:Transform> </dsig:Transforms> ... </dsig:Reference> </dsig:SignedInfo> ... </dsig:Signature> The dsig:Reference in the above example includes the entire soap envelope minus all the headers plus the header with id "123" inline inside of the soap:Header element. If someone else adds headers in parallel to header with id 123, the signature will still validate. If someone else wraps header with id 123 in a "Plain Brown Wrapper", the signature will fail. &Thomas. ] -----Original Message----- ] From: Hal Lockhart [mailto:hlockhar@bea.com] ] Sent: Friday, May 27, 2005 11:13 AM ] To: wss@lists.oasis-open.org ] Subject: [wss] Recently discover WSS security threat ] ] 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 ] ] ] --------------------------------------------------------------------- ] 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]