[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Issue 389: Detection of Duplicate IDs
"Martin Gudgin" <mgudgin@microsoft.com> wrote on 05/26/2005 04:31:42 AM: > 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; I mean wsu:Id is of ID type in any element (global). ID is of ID type in certain elements defined by XML Signature and Encryption, but might not be ID type in other elements (local). > > 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. Agree. The problem is not an XML problem. The problem is that different XML processing components might be aware of different subsets of the schema for the SOAP Envelope (Body and Header contents). > > > > > 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. Since every WSS implementation, regardless of what STs it supports, must know that wsu:Id, xenc:*/ID, and ds:*/ID attributes are of ID type the WSS Core can say: The wsse:Security processing MUST check for duplicate values from among the set of wsu:Id, xenc:*/ID, and ds:*/ID attributes. The SAML Token Profile can say: The wsse:Security processing MUST check for duplicate values from among the set of wsu:Id, saml:AssertionID, xenc:*/ID, and ds:*/ID attributes. Since we'd like the WSS processing to also check any other ID values too, the WSS Core can say: The wsse:Security processing SHOULD check for duplicate values from among the set of ID attributes that it is aware of. The wsse:Security processing MUST generate a fault if a duplicate ID value is detected. > > 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? Not sure how many implementaitons exist. It is a CR and the set of specified functionality we require is unlikely to change (any attribute named xml:id is of type ID). It seems likely support will eventually be widespread. The question is when? > > > > 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]