Re: Fwd: I-D Action:draft-pettersen-cookie-v2-03.txt

Hello Amit,

On Sun, 09 Nov 2008 21:36:09 +0100, Amit Klein <aksecurity@gmail.com>  
wrote:

> Section 2 defines "path-matching" as:
> "For two strings that represent paths, P1 and P2, P1 path-matches P2 if  
> P2 is a prefix of P1 (including the case where P1 and P2 string- compare  
> equal). Thus, the string /tec/waldo path-matches /tec."
>
> And I don't see any requirement in the document for the path to end with  
> slash (neither in $Path, nor in Path).
>
> So if I understand correctly, this means that /technology path-matches  
> /tec. Is this the desired behavior? I can think of operability issues

You understand correctly, and that is precisely what Netscape originally  
wanted:

      The path "/foo" would match "/foobar" and "/foo/bar.html".

> (e.g. two applications residing on the same server, one is called /app  
> and the other /app2). There may also be security implications (though in

Cookie specs released after Netscape's specifically require the client to  
send the $Path attribute with cookies that set a path, so that the  
receiving application can decide if the received cookie is one that it  
wants to look at.

It is, however, up to the site owner to choose appropriate cookie  
namespaces and resource namespaces.

We have seen a number of sites that actually end up having multiple  
cookies with the same name, but different paths and/or domains, causing  
problems. A prime example of this is amtrak.com's online booking system.

The reason I have chosen to discard the Path attribute in my proposed  
update is that it allowed users sharing the same host to interfere with  
each other.

The new SubPath attribute allows a site designer to further *restrict* the  
cookie's distribution (old version was to *increase* distribution), within  
the default path of the cookie (which is to and including the rightmost  
"/"; which means that a siteowner should ensure that "/user" is  
automatically redirected to "/user/"). The only way a cookie can be  
distributed to all paths on the server is by having a resource in the root  
set it (previously, a malicious script deep within the hierarchy could set  
such a wide distribution cookies).

Similar restrictions are also introduced for domain wide distribution of  
cookies; a host machine at the top of the domain must set such cookies,  
not one 5 levels down, as is done on some online services.


> BTW - typo? in section 3.3.2:
> "A Set-Cookie2 from a path /example1/example1 for SubPath=exam will be  
> accepted for the path /example/exam" - I think this should be:
> "A Set-Cookie2 from a path /example1/example1 for SubPath=exam will be  
> accepted for the path /example1/exam"

Thanks, fixed.

> Thanks,
> -Amit
>
>
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>>
>>
>> ------- Forwarded message -------
>> From: Internet-Drafts@ietf.org
>> To: i-d-announce@ietf.org
>> Subject: I-D Action:draft-pettersen-cookie-v2-03.txt
>> Date: Mon, 03 Nov 2008 23:15:01 +0100
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>>
>>     Title           : HTTP State Management Mechanism v2
>>     Author(s)       : Y. Pettersen
>>     Filename        : draft-pettersen-cookie-v2-03.txt
>>     Pages           : 31
>>     Date            : 2008-11-03
>>
>> This document specifies a way to create a stateful session with
>> Hypertext Transfer Protocol (HTTP) requests and responses.  It
>> describes three HTTP headers, Cookie, Cookie2, and Set-Cookie2, which
>> carry state information between participating origin servers and user
>> agents.  The method described here differs from both Netscape's
>> Cookie proposal [Netscape], and [RFC2965], but it can, provided some
>> requirements are met, interoperate with HTTP/1.1 user agents that use
>> Netscape's method.  (See the HISTORICAL section.)
>>
>> This document defines new rules for how cookies can be shared between
>> servers within a domain.  These new rules are intended to address
>> security and privacy concerns that are difficult to counter for
>> clients implementing Netscape's proposed rules or the rules specified
>> by RFC 2965.
>>
>> This document reflects implementation experience with RFC 2965 and
>> obsoletes it.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-03.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>>
>



-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Sunday, 9 November 2008 21:56:10 UTC