Security considerations, was Re: Area Director feedback on draft-reschke-webdav-search-15 re supported query complexity

Jim Davis wrote:

> Julian Reschke wrote:
>> 2) Supported query complexity

[[
   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 security considerations allow a server to reject queries due to their
>> complexity
>> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.7>).
>> Is there any kind of minimum we can require servers to support?
>
> In my opinion nothing is needed to address this.  For one thing, the
> security concern, as stated, applies to all query grammars, not just basic
> search, so if the spec addresses it, it either has to say something so
> general as to be useless, or it can say something about basic search
> alone.

Clients guessing by trial and error if their queries are allowed or not,
looks as a potential interoperability problem. However, the definition of
allowed queries is implementation-dependent, and if a query is "legitimate",
it should be already allowed; and if it is not legitimate, it may be
rejected or not (e.g: a non-legitimate query may be allowed if it is not
expensive and it does not compromise sensitive information).

I cannot think of a requirement which do not depend on the grammar. We could
assume that any grammar defines a select-like clause, criteria and scopes,
but that is not enough (for instance, the order element is specific of
DAV:basicsearch, and a query may be rejected because it requests too much
ordering on a big result set).

About DAV:basicsearch, one could say that if a PROPFIND succeeds in some
scope supporting DAV:basicsearch, then an equivalent query (unordered, with
no criteria, and selecting the same properties) should succeed unless any
property were not selectable. That is a formal minimum, but I don't think it
is useful enough, and I'm not sure if it should be a
requirement/recommendation. One could also say that if the criteria is
simpler than a minimum then it should succeed... but how would be that
minimum defined? How many and which expressions define a reasonable minimum?

Again, I think the answer is implementation-dependent.


Best Regards

Javier

Received on Monday, 30 June 2008 16:07:10 UTC