New Security considerations (was: Re: [Bug 184] )

Barry, can you provide more info or pointers on how a script can read  
another user's cookies?

Aside from that point of confusion, Julian, it sounds like you have  
some ways to improve this section, but I'm not sure which way you  
propose to go (e.g. whether the discussion of arbitrary content needs  
to be expanded or other).  Can you make a concrete proposal?

Lisa

On Nov 26, 2005, at 1:14 AM, Julian Reschke wrote:

>
> 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 Friday, 30 December 2005 22:11:36 UTC