an origin server.  (The user agent would then behave like one that is
   unaware of how to handle Set-Cookie response headers.)

   When the user agent terminates execution, it should let the user
   discard all state information.  Alternatively, the user agent may ask
   the user whether state information should be retained; the default
   should be "no".  If the user chooses to retain state information, it
   would be restored the next time the user agent runs.

   NOTE: User agents should probably be cautious about using files to
   store cookies long-term.  If a user runs more than one instance of
   the user agent, the cookies could be commingled or otherwise messed
   up.

7.2  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, 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 only set a Path for cookies that are related
   to the request-URI.

8.  SECURITY CONSIDERATIONS

8.1  Clear Text

   The information in the Set-Cookie and Cookie headers is unprotected.
   Two consequences are:

   1.  Any sensitive information that is conveyed in them is exposed
       to intruders.

   2.  A malicious intermediary could alter the headers as they travel
       in either direction, with unpredictable results.

   These facts imply that information of a personal and/or financial
   nature should only be sent over a secure channel.  For less sensitive
   information, or when the content of the header is a database key, an
   origin server should be vigilant to prevent a bad Cookie value from
   causing failures.







 
RFC 2109            HTTP State Management Mechanism        February 1997


8.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";
                         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.

8.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.

9.  OTHER, SIMILAR, PROPOSALS

   Three other proposals have been made to accomplish similar goals.
   This specification is an amalgam of Kristol's State-Info proposal and
   Netscape's Cookie proposal.

   Brian Behlendorf proposed a Session-ID header that would be user-
   agent-initiated and could be used by an origin server to track