[18112] in bugtraq
Re: cache cookies?
daemon@ATHENA.MIT.EDU (Rossen Raykov)
Fri Dec 15 18:38:07 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1251"
Content-Transfer-Encoding: 7bit
Message-Id: <003001c066a9$8bdb11b0$4c00000a@sage>
Date: Fri, 15 Dec 2000 10:13:14 -0500
Reply-To: Rossen Raykov <rraykov@sageian.com>
From: Rossen Raykov <rraykov@SAGEIAN.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
A little correction:
The assumption that the owner of the browser has visited the sites is not
correct all the time!
If the user is behind a proxy server, then even if someone else ware visited
the sites, then the time responses for the images will be the same like if
they are coming from the local cache!
Because of that the assumption that the visit was paid from the current user
is not correct.
Rossen Raykov
----- Original Message -----
From: <reinke@E-SOFTINC.COM>
To: <BUGTRAQ@SECURITYFOCUS.COM>
Sent: Thursday, December 14, 2000 2:06 AM
Subject: Re: cache cookies?
> Clover Andrew wrote:
> >
> > > http://www.princeton.edu/pr/news/00/q4/1205-browser.htm
> >
> > > or is it snakeoil?
> >
> > Well it *can* work. But I don't think the release's claims of
> > being 'very reliable', 'very dangerous [to privacy]' and
> > 'countermeasure-proof' are justified.
>
> Actually, it *does* work. We have on our site a
> working demonstration of the exploit, showing whether or not
> you've visited one or more of more than 80 different well known
> sites. The URL is
>
> http://www.securityspace.com/exploit/exploit_2a.html
>
> We've found with the demo that
>
> a) It is as reliable as the ability to find an image that
> would be cached by the browser. In fact, the timing is
> very accurate, but other factors can fool the mechanism.
> Out of the 80 odd sites we tested, we had 3 false negatives.
> b) Dangerous is subjective - a malicious site CAN find
> out what sites you have visited. How much they can do
> with it? Well..that's up to the imagination. Certainly
> I doubt (hope?) that larger organizations wouldn't
> stoop to this trick, but I honestly see nothing preventing
> advertising orgs and so on from not doing this, other
> than the uproar it would cause in the industry.
> c) Countermeasure proof...short of forcing all caching to
> be disabled, not sure what can be done. The technique
> demonstrated used JavaScript. It could have been done
> with Java, and it could even have been done to a
> certain extent without any scripting at all.
>
> >
> > This can easily be foiled by turning off JavaScript on
> > untrusted sites or setting cache policy to check for newer
> > versions of documents on every access. It is already likely
> > to be confused by shared proxy caches and setups where there
> > is no local cache.
>
> Javascript isn't required. It can be done also with Java, and
> can even be done (albeit with less accuracy and much more
> noticeably) without any scripting at all. Forcing to reload
> documents on every access however would seriously slow down
> network access in many cases.
>
> >
> > Calling it a 'cache cookie' is overselling it a bit IMHO
> > - it can't contain a value, only a yes/no response for each
> > possible key (URL), and an unreliable one at that. Trawling
> > many URLs at once would be slow, and the user would be more
> > likely to notice it.
>
> Cache cookie - clever terminology I agree. But as you note,
> it can store yes/no responses. As for the user noticing it?
> Not likely. If a page limited itself to trawling 10-15
> sites at a time, and only after the current page had loaded,
> the user might never notice at all.
>
> >
> > Since the act of running the cache-bug will itself cache the
> > target URL, it's also likely to get confused by reporting
> > false cache hits caused by itself and possibly other cache
> > bugs.
>
> That is actually trivial to bypass through a simple flag that
> indicates what has and has not been checked.
>
> >
> > I wouldn't be too worried though. JavaScript implementation
> > bugs and client-side-trojan problems are currently far
> > worse in my opinion.
>
> I agree.
>
> >
> > --
> > Andrew Clover
> > Technical Support
> > 1VALUE.com AG
>
> --
> ------------------------------------------------------------
> Thomas Reinke Tel: (905) 331-2260
> Director of Technology Fax: (905) 331-2504
> E-Soft Inc. http://www.e-softinc.com
> Publishers of SecuritySpace http://www.securityspace.com
>
