OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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]