[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Issue 389: Detection of Duplicate IDs
Mike, Comments/questions inline. Cheers Gudge > -----Original Message----- > From: Michael McIntosh [mailto:mikemci@us.ibm.com] > Sent: 17 May 2005 18:51 > To: WSS > Subject: [wss] Issue 389: Detection of Duplicate IDs > > One of the goals for SOAP processing is to allow processing > without schema > validation. Processing of ID attributes and ID references requires > knowledge of which attributes are of ID type. Different processing > components/layers may be aware of different subsets of ID > attributes. For > example the WSS processing component would likely know that: > wsu:Id is a global ID, > ID is a local ID in the context of XML Signature and XML > Encryption elements, > AssertionID is a local ID in the context of Security > Tokens based > on SAML 1.1 Assertions, > ID is a local ID in the context of Security Tokens > based on SAML > 2.0 Assertions. > Other header or application processing components may be > aware of other ID > attributes. It's not clear to me what you mean when you use the words 'global' and 'local' above. Let me make some statements and you can let me know if they match your expectations; 1. There is a single ID space in XML. 2. All attributes of type ID, whether they are global attributes like wsu:Id or local attributes like xenc:EncryptedData/@ID share that space. 3. If there are any duplicate values amongst any of the attributes of type ID, then the XML document is not valid. Note that not valid is not the same as not well-formed. > > Even when processing components are aware of and expected to > treat certain > attributes as IDs, they may not use XML Schema validation to > do so. This > might unintentionally allow duplicate ID values to go undetected. I think the WSS stacks will have to at least collect up all the wsu:Id, xenc:*/ID and ds:*/ID attributes and check them for uniqueness. I can also see given implementations that support SAML tokens including those attributes too. > > Following a some simple examples which illustrate problems > that may occur > due to inconsistent processing of ID attributes by different layers: > > In the following message the originator/signer created a SOAP Body > containing "Goodbye". An adversary intercepted the message > and moved the > signed content and replaced it. Since the wsse:Security > header processing > scans the message in order, the first instance of an ID > attribute with the > value "theBody" is used. However the application bases its > processing on > the actual SOAP Body. > > <soap:Envelope> > <soap:Header> > <wsse:Security> > <ds:Signature> > references "#theBody" > </ds:Signature> > </wsse:Security> > <soap:Body wsu:Id="theBody">Goodbye</soap:Body> > </soap:Header> > <soap:Body wsu:Id="theBody">Hello</soap:Body> > </soap:Envelope> Yup, that's bad! > > In the following message the originator/signer created a SOAP Body > containing IDREFs to elements in the soap:Header. An > adversary intercepted > the message and added an element with a duplicate ID value. Since the > wsse:Security header processing scans the message in order, the first > instance of an ID attribute with the value "theDestinationAccount" is > used. However, since the soap:Body processing scans the > message in reverse > order, the second ID is used. > > <soap:Envelope> > <soap:Header> > <wsse:Security> > <ds:Signature> > references "#thebody", "#theOriginAccount", and > "#theDestinationAccount" > </ds:Signature> > </wsse:Security> > <accountInfo wsu:Id="theOriginAccount"> > <bankId>Bank Of America</bankId> > <number>123456</number> > <pin>7890</pin> > </accountInfo> > <accountInfo wsu:Id="theDestinationAccount"> > <bankId>Bank Of New York</bankId> > <number>654321</number> > <pin>0987</pin> > </accountInfo> > <accountInfo wsu:Id="theDestinationAccount"> > <bankId>BANK OF NIGERIA</bankId> > <number>666666</number> > <pin>6666</pin> > </accountInfo> > </soap:Header> > <soap:Body wsu:Id="theBody"> > <fundTransfer amount="1000000.00" units="USD"> > <originAccount idref="#theOriginAccount"/> > <destinationAccount idref="#theDestinationAccount"/> > </fundTransfer> > </soap:Body> > </soap:Envelope> Yup, that's bad too. > > The problems described in the above messages can be avoided > by having the > wsee:Security processing check for duplicate ID values for the ID > attribute that it is aware of. However, the following > alternate form of > the second message relies on the fact that the wsse:Security > processing > does not know about "myID" and the SOAP Body processing > treats myID with > higher priority than wsu:Id. > > <soap:Envelope> > <soap:Header> > <wsse:Security> > <ds:Signature> > references "#thebody", "#theOriginAccount", and > "#theDestinationAccount" > </ds:Signature> > </wsse:Security> > <accountInfo wsu:Id="theOriginAccount"> > <bankId>Bank Of America</bankId> > <number>123456</number> > <pin>7890</pin> > </accountInfo> > <accountInfo wsu:Id="theDestinationAccount"> > <bankId>Bank Of New York</bankId> > <number>654321</number> > <pin>0987</pin> > </accountInfo> > <accountInfo myID="theDestinationAccount"> > <bankId>BANK OF NIGERIA</bankId> > <number>666666</number> > <pin>6666</pin> > </accountInfo> > </soap:Header> > <soap:Body wsu:Id="theBody"> > <fundTransfer amount="1000000.00" units="USD"> > <originAccount idref="#theOriginAccount"/> > <destinationAccount idref="#theDestinationAccount"/> > </fundTransfer> > </soap:Body> > </soap:Envelope> And that's bad too... > > I propose that we add the following requirements to the core: > > The wsse:Security processing SHOULD check for duplicate ID > values from > among the set of ID attributes that it is aware of. > The wsse:Security processing SHOULD generate a fault if a > duplicate ID > value is detected. These seem reasonable to me. I'm happy adding them to the spec. > > Question: Are we going to add support for xml:id > (http://www.w3.org/TR/xml-id/) to Section 4? xml:id isn't a Rec yet. Do we know how widespread implementations are? > > Thanks, > Mike > > Michael McIntosh > Web Services Security Group > Security, Networking, and Privacy Department > IBM Research > > --------------------------------------------------------------------- > 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_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]