[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Issue 399: Proposed Security Consideration Text
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]