view release on metacpan or  search on metacpan

rfc/rfc2965.txt  view on Meta::CPAN

7.  SECURITY CONSIDERATIONS

7.1  Protocol Design

   The restrictions on the value of the Domain attribute, and the rules
   concerning unverifiable transactions, are meant to reduce the ways
   that cookies can "leak" to the "wrong" site.  The intent is to
   restrict cookies to one host, or a closely related set of hosts.
   Therefore a request-host is limited as to what values it can set for
   Domain.  We consider it acceptable for hosts host1.foo.com and
   host2.foo.com to share cookies, but not a.com and b.com.

   Similarly, a server can set a Path only for cookies that are related
   to the request-URI.




Kristol & Montulli          Standards Track                    [Page 21]

RFC 2965            HTTP State Management Mechanism         October 2000


7.2  Cookie Spoofing

   Proper application design can avoid spoofing attacks from related
   domains.  Consider:

      1. User agent makes request to victim.cracker.edu, gets back
         cookie session_id="1234" and sets the default domain
         victim.cracker.edu.

      2. User agent makes request to spoof.cracker.edu, gets back cookie
         session-id="1111", with Domain=".cracker.edu".

      3. User agent makes request to victim.cracker.edu again, and
         passes

         Cookie: $Version="1"; session_id="1234",
                 $Version="1"; session_id="1111"; $Domain=".cracker.edu"

         The server at victim.cracker.edu should detect that the second
         cookie was not one it originated by noticing that the Domain
         attribute is not for itself and ignore it.

7.3  Unexpected Cookie Sharing

   A user agent SHOULD make every attempt to prevent the sharing of
   session information between hosts that are in different domains.
   Embedded or inlined objects may cause particularly severe privacy
   problems if they can be used to share cookies between disparate
   hosts.  For example, a malicious server could embed cookie
   information for host a.com in a URI for a CGI on host b.com.  User
   agent implementors are strongly encouraged to prevent this sort of
   exchange whenever possible.

7.4  Cookies For Account Information

   While it is common practice to use them this way, cookies are not
   designed or intended to be used to hold authentication information,
   such as account names and passwords.  Unless such cookies are
   exchanged over an encrypted path, the account information they
   contain is highly vulnerable to perusal and theft.

8.  OTHER, SIMILAR, PROPOSALS

   Apart from RFC 2109, three other proposals have been made to
   accomplish similar goals.  This specification began as an amalgam of
   Kristol's State-Info proposal [DMK95] and Netscape's Cookie proposal
   [Netscape].




Kristol & Montulli          Standards Track                    [Page 22]

RFC 2965            HTTP State Management Mechanism         October 2000


   Brian Behlendorf proposed a Session-ID header that would be user-
   agent-initiated and could be used by an origin server to track
   "clicktrails".  It would not carry any origin-server-defined state,
   however.  Phillip Hallam-Baker has proposed another client-defined
   session ID mechanism for similar purposes.

   While both session IDs and cookies can provide a way to sustain
   stateful sessions, their intended purpose is different, and,
   consequently, the privacy requirements for them are different.  A
   user initiates session IDs to allow servers to track progress through
   them, or to distinguish multiple users on a shared machine.  Cookies
   are server-initiated, so the cookie mechanism described here gives
   users control over something that would otherwise take place without
   the users' awareness.  Furthermore, cookies convey rich, server-
   selected information, whereas session IDs comprise user-selected,
   simple information.

9.  HISTORICAL

9.1  Compatibility with Existing Implementations

   Existing cookie implementations, based on the Netscape specification,
   use the Set-Cookie (not Set-Cookie2) header.  User agents that
   receive in the same response both a Set-Cookie and Set-Cookie2
   response header for the same cookie MUST discard the Set-Cookie
   information and use only the Set-Cookie2 information.  Furthermore, a
   user agent MUST assume, if it received a Set-Cookie2 response header,
   that the sending server complies with this document and will
   understand Cookie request headers that also follow this
   specification.

   New cookies MUST replace both equivalent old- and new-style cookies.
   That is, if a user agent that follows both this specification and
   Netscape's original specification receives a Set-Cookie2 response
   header, and the NAME and the Domain and Path attributes match (per
   the Cookie Management section) a Netscape-style cookie, the
   Netscape-style cookie MUST be discarded, and the user agent MUST
   retain only the cookie adhering to this specification.

   Older user agents that do not understand this specification, but that
   do understand Netscape's original specification, will not recognize
   the Set-Cookie2 response header and will receive and send cookies