Re: making progress on State-Info

Dave Kristol:
>
>Ari Luotonen <luotonen@netscape.com> wrote:
>>Furthermore, a shortcoming in the state-info spec as opposed to the
>>Cookie spec is that state identifiers cannot be shared between hosts
>>(unless yet some more infrastructure is laid down on the server
>>cluster side).  Not all systems are self-contained in a single host,
>>and therefore there is value in being able to share cookies accross
>>different hosts.
>
>This is definitely true.

It is also definitely true that the `domain=' cookie feature as
proposed by Netscape has some serious worst case privacy problems. A
discussion of this, using co.uk domains as an example I believe, was
posted a while ago.

I think a middle ground can be found here: we could either make use of
large domains (like co.uk) more visible to the user, or strengthen the
restrictions on the `domain=' header from the current

|         Only hosts within the specified domain can set a cookie for a
|         domain and domains must have at least two (2) periods in them
|         to prevent domains of the form: ".com" and ".edu".

to something like

          A host can only set cookies for a domain DOMAIN_NAME if its
          host name has the form HOST.DOMAIN_NAME where HOST may not
          contain any periods.  Also, domains must have at least two
          (2) periods in them to prevent domains of the form: ".com"
          and ".edu".

When writing the above, I went over the domain restrictions in the
cookie proposal again, and it occurs to me that there is also a
_security_ problem involved.  Take for example a shopping server named

 www.acme.co.uk

that uses cookies like CUSTOMER=WILE_E_COYOTE to identify customers.
Now, a malicious site

 www.roadrunner.co.uk

could send out the following header in its responses:

 Set-Cookie: CUSTOMER=BILL_GATES; path=/; domain=co.uk;
        expires=Wednesday, 09-Nov-99 23:12:40 GMT

If WILE_E_COYOTE first goes to www.roadrunner.co.uk and then to
www.acme.co.uk, the acme server will get

 Cookie: CUSTOMER=BILL_GATES

without any hint of the fact that this cookie was not set by the acme
server itself.  This will presumably drastically reduce
WILE_E_COYOTE's chances of getting acme to send him a
ROCKET_LAUNCHER_0001.  And if the real BILL_GATES happens to be using
acme.co.uk at the same time, lots of additional interesting things
will happen.

So basically, with this domain feature, you cannot trust any cookie
value you get.  A malicious site could flood your server with 500
users all called BILL_GATES.  The problem gets even bigger if you want
to use cookies as anonymous, but unique, user identifiers.

Hm.  It seems that to completely solve this cookie spoofing problem,
even my strengthening for the domain restriction above will not be
sufficient.  There are a number of ISPs that offer host names like
companya.isp.net and companyb.isp.net to competing companies.  Maybe
the hostname of the host that last changed the cookie will have to be
sent along with any Cookie that is set for a domain?

[...]
>[Sorry, Larry M.]  Yes, I agree that Cookies are used and work for
>real-life applications.

For the record, Lou Montulli recently sent me mail saying that he was
told that the number of sites using cookies is in the hundreds.

>  I welcome the possibility to improve them.  Many
>of us await a more detailed specification of the current Cookie mechanism
>so we can do just that.

Count me among the waiting.  Netscape has been very silent about
cookies on this list in the past.  Am I the first one to think up the
above security problem, or have things like this already been found
and solved within Netscape without us knowing about it?

>Dave Kristol

Koen.

Received on Sunday, 10 December 1995 13:19:21 UTC