131509 - Cookies are accepted for top-level domains

Status: RESOLVED DUPLICATE of bug 8743

(Core :: Networking: Cookies, defect)

Description

[Dan Mellem]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311
BuildID:    200231104

Sorry, I couldn't find the URL again so I don't have an example. Perhaps someone
could replicate...

While I was on a UK web page, one of the ads set a cookie for .CO.UK which would
be a privicy issue since it could be retrieved from any other domain.

May be related to bug 58497.


Reproducible: Couldn't Reproduce
Steps to Reproduce:
An example may need to be built...
Go to a site that sets a cookie for .CO.UK


Actual Results:  The browser saved the cookie.

Expected Results:  The browser should not accept TLD cookies.

I noticed this under Mozilla 0.9.8. I am not running 0.9.9. I am unable to
verify if this is still a bug.

Comment 1

[Stephen P. Morse]

Marking this as a dup of bug 8743.  On the surface of it, that bug looks like 
its about something altogether different.  But if you read through the entire 
bug report, you'll see that the a.b.co.nz problem is discussed in all its gory 
details, and after going round in circles we convinced ourself that there is no 
practical solution to the problem (proposed solutions that looked good in theory 
actually broke some significant sites because those sites had errors in them).

But don't be concerned about it being a privacy issue.  On the contrary it's 
just the opposite.  Rather than permitting a malicious site from capturing some 
other site's cookies, it allows a site to leak all its own cookies.  If 
anything, it could be considered as a DOS attack, but not a privacy or security 
attack.

*** This bug has been marked as a duplicate of 8743 ***

Comment 2

[Dan Mellem]

I think it is a security risk because it allows a persistant cookie across
domains. Although it could be screwed with by other sites, an ad site, for
example, can create some type of GUID and set it at a higher domain. E.G., if
Doubleclick could create a DOUBLECLICK_GUID=____ cookie for .COM, .NET, .CO.UK,
.LTD.UK, etc. they could gather a lot of information. If they could later tie
the GUIDs from each TLD then they would have the browsing habits of a single
user across all domains. [Unless I'm totally missing something...]

Reading through bug 8743, it seems like the example you gave
(http://people.netscape.com.../morse/) should fail since there is no such TLD as
"netscape.com..." but it still works even in the latest build. The domain should
be parsed before it is passed to a server or acted upon, IMO.

Comment 3

[Stephen P. Morse]

doubleclick doesn't have to set the cookie for the top level domain to do what 
you just described.  They only need to set it for .doubleclick.com and since 
they get called on to deliver ads for all their partner sites, they will be 
collecting browsing habbits of all the users of all those sites.

By allowing doubleclick to set the cookie up one level higher up, we are not 
giving doubleclick any more power than they had before.  But we are allowing 
other sites to see the cookies that doubleclick set, and to possibly decode 
them.  That's a violation of doubleclicks privacy, so doubleclick wouldn't want 
to do that.

Comment 4

[Dan Mellem]

True, but perhaps that was a bad example. I can block cookies from
.DOUBLECLICK.COM but I couldn't block from .CO.UK because it would affect too
many sites. I could also block 3rd party cookies. Plus, if there's a group of
sites that shared data they could have a common cookie so they could gather data
even if the web user is not a "member" at the site they're browsing.

Comment 5

[Stephen P. Morse]

I'm not arguing that it wouldn't be nice to fix this.  But, unfortunately, there 
is no practical fix, as described in gory detail in bug 8743.  And breaking 
major sites, no matter how erroneous there website is, is not a practical fix.