W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 2008

Re: Security considerations in DASL

From: Jim Davis <jrd3@alum.mit.edu>
Date: Mon, 07 Jul 2008 22:28:48 -0400
Message-ID: <4872D0E0.5060404@alum.mit.edu>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Javier Godoy <rjgodoy@fich.unl.edu.ar>, www-webdav-dasl@w3.org

Julian Reschke wrote:
> Javier Godoy wrote:
>> ...
>> [[
>>   A query must not allow one to retrieve information about values or
>>   existence of properties that one could not obtain via PROPFIND. (e.g.
>>   by use in DAV:orderby, or in expressions on properties.)
>> ]]
>> IMHO this should be an uppercase MUST NOT, in order to emphasize that 
>> must comply with the Access Control Protocol (RFC 3744).
>> (At least, the DAV:read privilege must be honored, as well as 
>> DAV:read-acl
>> and DAV:read-current-user-privilege-set if DAV:acl is
>> searchable/selectable/sortable.)
The original intention of this had nothing to do with access control.  
For one thing, there was no access control back then.  The point is that 
a server should not expose properties for use in orderby or where 
expressions that it would not be willing to have exposed via PROPFIND, 
because a clever caller can deduce the value of a property even if it 
could not read it directly.  For example, suppose the salary property is 
considered private, but  if one selects where salary  > n one finds all 
people whose salary exceeds n  By gradually increasing n, one can 
identify the salary even though could not read salary directly.

Having said that, I don't know how to say this in the strict language of 
MUST NOT.  For one thing, it depends on the query grammar.  With 
basicsearch, you can do this with DAV:where or DAV:orderby, and perhaps 
in other ways as well.  With other grammars, perhaps there are other 
ways to leak the information.

Jim Davis
Received on Tuesday, 8 July 2008 02:29:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:44 UTC