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

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 UTC