This is the celebrated journal of Mr. Simon Collison A.K.A Colly

Background Images Security Flaw?

24th May 2004

Yesterday, Simon Willison posted a short overview of some current visited links methods over at Sitepoint, mentioning the method I use here. Good stuff, but is there a security flaw when using background images with CSS link styles?

The link itself does not generate a hit, so we’d never know where the user went, but it does if a background image is ascribed to that style. Yesterday, Jesse Ruderman commented:

I find it amusing that someone is using background images in combination with :link / :visited. That combination also leads to a privacy hole that lets any web site you visit find out e.g. which Slashdot articles you read.

Hmm. It seems there is a potential security issue, as he flagged in 2000 over at Bugzilla (Bug 57351). The comments raised there in response to Jesse’s alert range from major concern through to very little. Jesse and the team argue that it might be possible to track a user’s progress for illegal gains:

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 first sentence in the above quote is, I think, key to whether we dare use background images or not. If I’m following the discussion correctly, the problem arises when using a seperate link style for every or certain links. By attaching individual styles to individual links, it may well be possible to launch malicious commands based on what the end user does (maybe by timing performance with javascript, or forcing certain elements off screen etc). Jesse goes into more detail about the potential for this in the article.

Potentially, tracking pages not created by the attacker is dangerous, and it’s possible because a:visited doesn’t look at domains. The user would have to visit the booby-trapped page though, and like anything else, we have to trust that this isn’t happening on a page we navigate to.

However, CollyLogic only uses two sets of link styles, spanning many, many links. Therefore, using this method seems far too general to allow me to chart your movements. Which of the many sidebar links had you clicked? How do I differentiate between them unless I apply an individual style to each one? The a:visited element itself is open to exploitation here, regardless of the use of unique background images. That said, it seemed worthwhile to point out Jesse’s findings in response to the focus the ‘ticked’ links have been getting recently. I’ll let you decide whether it could be a minor or major concern.

But don’t worry about me. I’m an honest, responsible background-image user.


# Simon Willison responded on 24th May 2004 with...

Whoa! I’d never seen that argument before. It certainly is a security issue - in fact, it’s quite a nasty one. Browsers simply aren’t meant to allow sites to delve in to the user’s history, but that’s exactly what :visited background images allow you to do.

# Simon Snorkeller responded on 24th May 2004 with...

Fascinating stuff, though not quite as malicious as some of the tricks that continue to plague the Windows world, such as dialers and files that attempt to execute in the background.

Still, perhaps the subtle stuff is more devious, as anyone who’s ever hidden tiny graphics within mass emails in order to track response will tell you…!

Perhaps, and it’s a *big* perhaps, some kind of website kite mark is needed, signifying to the user (and maybe the browser) that a site has passed a set of independent safety, accessibility and best-practice tests. Of course, many of us use an obvious display of standards-compliance in a similar, informal way, and administration would be a complete can’o'worms, but it’s thought.

# Simon Snorkeller responded on 24th May 2004 with...

Colly, I reckon you’ve got some kind of cache issue on displaying the number of comments on the index page. Just submitted a second comment and the display is still 1 after a Safari reset.

# Simon Collison responded on 24th May 2004 with...

I blame the server, but I’ll have a look.

A short-term good practice method might be to allow users to switch off background images:

Small text | Large text | Backgrounds off (?)

The (?) a link to an explanation. That way if someone is concerned, at least they have an option. Alternatively, maybe browsers could provide a preferences choice to turn such styles off.

I wonder how many sites (might) use transparent background image links though. Crafty swines…

# Eby responded on 24th May 2004 with...

As it stands now, according to your tutorial, you only use one image for all links states, so there really is no way for you to tell anything since the visited change is performed by the browser. I can see the potential for problems in other instances, but nothing that gets me alarmed compared to some of the other problems out there.

# Jim Dabell responded on 24th May 2004 with...

It’s not just :visited that is affected.  I’ve just checked, and :active is affected too.  That means you can track outbound traffic even without them coming back to visit your page.

Blocking background images isn’t enough.  Generated content and pretty much anything that references an external resource is a problem.  User-agents implementing aural CSS would have a problem with the play-during property, for example.  You’d have to have a generic “block external resources on link pseudo-classes” setting.

# jgraham responded on 24th May 2004 with...

If you read the bug, :visited in general may be exploited, not just visited in conjunction with images. I typed out a sample exploit but I had a problem with the comment form and lost it :(

# jgraham responded on 24th May 2004 with...

To be more precise, the problem is documented in the bug that the linked bug is duped to and the generic problem is with <style

:visited. There is also a demonstration of a CSS-free exploit of the same type which uses the fact that pages being pulled from cache will arrive sooner than those coming over the network.

# Sencer responded on 24th May 2004 with...

Wow, this is certainly an interesting finding. I had a very similar eye-opener on another security issue a while ago, which I wrote about here:

GET considered harmful; Sometimes.

It’s sometimes intriguing how “out of the ordinary” usages of well known principles can lead to whole new situations.

Thanks for the link to the bugzilla item.

# jgraham responded on 25th May 2004 with...

Let’s try again. The generic problem is using <style

:visited syle or not.

# jgraham responded on 25th May 2004 with...

I give up. It looked fine in the preview :(

# Jesse Ruderman responded on 25th May 2004 with...

I think jgraham was trying to say “The generic problem is using [CSS] to determine if a link has the :visited style or not”.

# Simon Collison responded on 25th May 2004 with...

Once again, my apologies about the comments form performance this week - strange.

Thanks for the clarification Jesse. Hope you didn’t mind me flagging this issue up on here…

# jgraham responded on 25th May 2004 with...


# Andras responded on 25th May 2004 with...

Nice problem… There is a solution, that you didn’t mention before, and maybe better than disabling backgrounds totally: just pull down all the background images that has been defined not depending on if it will be shown or not. I think this way the site owner won’t be able to detect if the client visited the link or not?

Responses are now disabled Your ability to respond is disabled automatically some 30 days after articles are published, or manually much sooner if spamming guttersnipes target a particular article.

Prev 52 Next

Superfluous Aside

Archived in HTML & CSS, Design & Web

There are 15 responses

External References

Copyright © Mr. Simon Collison 2003-2017. Protected and licensed under a Creative Commons License. Grab the RSS feed

Engineered in Nottingham, scaffolded by ExpressionEngine, steam-pumped by United & kept alive with tea and hugs.