[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Issue 399: Proposed Security Consideration Text
This may be problematic. If I ask the API to an XPath class to execute an XPath instance against an XML instance, it may return something [null] or a real node value. In Java, it might come down to writing the exact code for this. As stated in the J2EE JavaXpath API spec "The arguments, |null| is a valid value" It also throws an XPathFunctionException This inevitably comes down to someone being careful enough to write if ((this.representations != null) && (this.representations.equals("theNodeValue") {//do something} I feel it all comes down to implementation issues which may be better address in WS-I or even a WSS TC interoperability profile recommendation. Having said that, I am still a newbie in this TC and don't have a feel for the desired level of technical constraints WRT this issue. My $0.02 worth Duane DeMartini, Thomas wrote: >I believe it is actually more than the latter. "Validation" of the >expression, as I understand it (Mike or Rich can perhaps clarify), would >include at least the following steps: >* checking that the xpath syntax is valid >* checking that the reference uri points to the soap:Envelope >* checking that the xpath resolves to something in the soap:Envelope >* checking that the thing the xpath resolves to is canonically >equivalent to the post-transform result of the reference > >&Thomas. > >] -----Original Message----- >] From: Duane Nickull [mailto:dnickull@adobe.com] >] Sent: Thursday, June 16, 2005 3:22 PM >] To: DeMartini, Thomas >] Cc: wss@lists.oasis-open.org >] Subject: Re: [wss] Issue 399: Proposed Security Consideration Text >] >] I am unclear what the intent of 'validation' is. Is it to ascertain >] that the XPath syntax itself is valid or that it actually resolves to >] something in the XML instance file. Erros in the latter may happen >but >] might not be the fault solely of the XPath statement. >] >] Duane >] >] >] DeMartini, Thomas wrote: >] >] >On this section, I also suggest adding "and validation of those >] >expressions by receivers" immediately after "References using XPath >] >transforms with Absolute Path expressions". >] > >] >&Thomas. >] > >] >] -----Original Message----- >] >] From: Duane Nickull [mailto:dnickull@adobe.com] >] >] Sent: Wednesday, June 15, 2005 10:56 AM >] >] Cc: wss@lists.oasis-open.org >] >] Subject: Re: [wss] Issue 399: Proposed Security Consideration Text >] >] >] >] My take(s) inline: >] >] >] >] Granqvist, Hans wrote: >] >] >] >] >Hi all, quite good text. Just some proof-reading comments: >] >] > >] >] >General comment: There seems to be too many capitalized words, >e.g., >] >] >Shorthand, References, Body, Absolute Path, Document, and so on, >] >which >] >] >are not found capitalized in the specs. >] >] > >] >] > >] >] > >] >] >>XML Signatures using Shorthand XPointer References (AKA >] >] >>IDREF) protect >] >] >>against the removal and modification of XML elements; but do >] >] >>not protect >] >] >>the location of the element within the XML Document. >] >] >> >] >] >> >] >] > >] >] >"the element" is undefined in this sentence. Should it be >] >] >"this element/these elements"? >] >] > >] >] > >] >] DN - I perceived this as referring to the "xml elements" noted just >] >] above it. Grammatically correcting it to "the elements" would be >] >correct. >] >] >] >] > >] >] > >] >] >>Whether or not this is a security vulnerability depends on >] >] >>whether the >] >] >>location of the signed data within its surrounding context has >any >] >] >>semantic import. This consideration applies to data carried >] >] >>in the SOAP >] >] >>Body or the Header. >] >] >> >] >] >> >] >] > >] >] >What does "...within its surrounding context has any semantic >] >] >import" mean? Does it mean "has semantic imports within its >] >] >surrounding context?" If so, what the heck does that mean? :) >] >] >Can we exemplify? >] >] > >] >] >The sentence is a bit heavy. Can it be rewritten to begin "Use of >] >] >IDREFs is a security vulnerability if the location of the >referenced >] >] >signed data..."? >] >] > >] >] > >] >] DN - I think the concept here is "determinism". If the schema >itself >] >is >] >] deterministic, then there should be no problem however if the >schema >] >is >] >] not and there are potential issues arising from that, to me that >] >] indicates a fault in the actual data model itself or the process >] >someone >] >] used to derive the schema from the data model. Such is worthwhile >] >] noting but out of scope for rectifying in a this spec. We cannot >] >] constrain people to write good schemas ;-) >] >] >] >] Cheers. >] >] >] >] Duane >] >] >] >] > >] >] > >] >] >>... >] >] >> >] >] >> >] >] > >] >] > >] >] > >] >] >>In the general case of XML Documents and Signatures, this >] >] >>issue may be >] >] >> >] >] >> >] >] > >] >] >Unclear what "this issue" relates to here. >] >] > >] >] > >] >] > >] >] >>resolved by signing the entire XML Document and/or strict XML >Schema >] >] >>specification and enforcement. However, because elements of the >SOAP >] >] >>... >] >] >> >] >] >> >] >] > >] >] >Strict schema checking won't catch all SOAP header wrapping >attacks >] >] >outlined in email threads/TC calls (I believe), so "and/or" seems >too >] >] >loose, but I may be way off here. >] >] > >] >] >Thanks, >] >] >Hans >] >] > >] >] > > >>--------------------------------------------------------------------- >> >> >] >] >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 >>> >>> >] >> >] >> >] >] > >] >] > >] >] > >] >] >] >] >--------------------------------------------------------------------- >] >] 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 >] > >] > >] >--------------------------------------------------------------------- >] >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]