Re: Security considerations in DASL

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 
>> SEARCH
>> 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
http://www.econetwork.net/~jdavis
jrd3@alum.mit.edu
416-929-5854

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