RE: Security: Cookies

Cookies are used to establish a session over a session-less protocol (as
HTTP).

This means cookies don't provide access to personal information that is NOT
send
to the web server/other side.

Another e-mail "Cookies Security Vulabilities" also send by me describes
also this,
also some recommendations, however it may not incorporate all issues that
are discusses
in these e-mails.........

-----Original Message-----
From: www-talk-request@w3.org [mailto:www-talk-request@w3.org]On Behalf
Of Clover Andrew
Sent: maandag 20 maart 2000 14:53
To: 'www-talk@w3.org'
Subject: Re: Security: Cookies


Kevin J. Dyer <kdyer@draper.com> spake thusly:

> But the cookie can only travel from the User Agent to www.a.com or if
> it was set as a domain cookie all of a.com or conversely b.com.

Yes, the cookie is set on b.com. The user simply doesn't realise that
any information has been sent to b.com because the URL bar says a.com.

> Unless you have given a.com and b.com specific information that they
> can place in their cookies.

The information is something you don't have to give, because it is
inherent in the request: the URI of the document on a.com. It's
clear that a.com needs to know this to service the request, but it
often then passes the information along to b.com by embedding that
information in part of a URI your browser will proceed to request
from b.com. Typically this is done in the query-string of an
<img> src attribute.

So then your browser sends something that identifies you to b.com
(the cookie) and something that identifies what you are doing on
a.com (the URI) to the unrelated site b.com.

This is badness.

> A better solution does exist but the two big browser developers
> haven't given the community any indication that they want to
> support it, Digest Authentication.  At least for the sites that
> require authentication.

I agree that digest auth is a Good Thing, but I don't think it
relates to this particular problem. At the moment the workaround
for lack of digest is to use basic auth over HTTPS, rather than
cookies. A banner ad provider is not interested in using cookies
as a means of authentication, only tracking.

> The web has always required trust on both ends of the connection.
> The end-user needs to be able to tweak that trust more,
> now that the web has become more commercialized.

Such options are a good thing indeed, and I like Internet Explorer's
approach. The problem is that most security options are turned
off by default, most users don't bother look at them, and many sites
exist that refuse to work with anything but the default settings.
This is sloppy design, of course, but that's life.

I can't see any legitimate uses of cookies which would be
disallowed by the strategy of denying cookies to <img>/<embed>/
<object>/<applet> -generated HTTP requests where the cookie to
be passed to the embedded URI would not also be passed to the
URI in the location box.

Frames and popups are more difficult. Both can be seeded with
URI information from a.com, and both can appear without any
identifying location, thus hiding an access to b.com, but both can
contain full web sites in their own right, where cookies ought
really to work. For example, see askjeeves.com's use of a top
frame with the actual site below.

Personally I am against such use of frames and popups, but they
are unlikely to go away. :-(

--
Andrew Clover
Technical Support
1VALUE.com AG

Received on Monday, 20 March 2000 10:13:42 UTC