W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 184] New: Section 19.8 added with no open issue nor WG consensus

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 26 Nov 2005 10:14:17 +0100
Message-ID: <43882769.5010500@gmx.de>
To: Cullen Jennings <fluffy@cisco.com>
CC: bugzilla@soe.ucsc.edu, WebDav <w3c-dist-auth@w3.org>

Cullen Jennings wrote:
> 
> Do you think it is wrong?

It's not necessarily wrong, but it definitively needs to be discussed 
and understood. This is a Security Consideration, and if we add 
something new *here*, we better make sure it's correct.

Quoting: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-08.html#rfc.section.19.8>:

>    HTTP has the ability to host scripts which are executed on client
>    machines.  These scripts can be used to read another user's cookies
>    and therefore may provide an attacker the ability to use another
>    user's session, assume their identity temporarily and gain access to
>    their resources.  Other attacks are also possible with client-
>    executed scripts.

1) How would a script be able to read another user's cookies? If this is 
about potential bugs in user agents, it should say so. The way it's 
written now confuses me, because I don't understand the risk yet.

2) And yes, letting people store arbitrary content on a shared server 
introduces the same security problems when people share a file server, 
or people download code from the Web. In particular, this includes 
executables, or file types with security issues (such as the recent 
JPG-related attacks). RFC2518bis *could* talk about that, but then this 
really needs to be expanded a lot.

>    WebDAV may worsen this situation only by making it easier for a Web
>    server to host content provided by many different authors (making it
>    harder to trust the content providers) and to host content with
>    restricted access alongside public pages (see particularly RFC3744).

How is the latter a security problem?

>    HTTP servers may mitigate some of these threats by filtering content
>    in areas where many authors contribute pages -- the server could, for
>    example, remove script from HTML pages.

It could also run virus scanners on new content.

>    This vulnerability should provide yet another reason for server
>    implementors and administrators not to replace authentication
>    mechanisms with cookie-based session tokens if there's any sensitive
>    information relying on the authenticated identity.

This relates back to the cookie discussion above. I prefer HTTP auth as 
well, but I don't think this is the right place to evangelize it.

>    HTTP and WebDAV client implementors might consider locking down the
>    use of scripts and cookies based on these considerations.


Best regards, Julian
Received on Saturday, 26 November 2005 09:15:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT