CollyLogic: Background Images Security Flaw?

Background Images Security Flaw?

24th May 2004

Simon Willison yesterday 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 Collison published this on 24/05/04, at 8:31 AM

Comments

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.

24/05 at 11:18 from Simon Willison

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.

24/05 at 12:05 from Simon Snorkeller

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.

24/05 at 12:07 from Simon Snorkeller

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…

24/05 at 12:35 from Simon Collison

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.

24/05 at 13:28 from Eby

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.

24/05 at 13:37 from Jim Dabell

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 :(

24/05 at 14:07 from jgraham

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.

24/05 at 14:11 from jgraham

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.

24/05 at 15:34 from Sencer

Let’s try again. The generic problem is using <style:visited syle or not.

24/05 at 23:58 from jgraham

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

24/05 at 23:59 from jgraham

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

25/05 at 02:38 from Jesse Ruderman

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…

25/05 at 02:47 from Simon Collison

getComputedStyle

25/05 at 03:38 from jgraham

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?

25/05 at 10:59 from Andras

Note that comments are disabled 30 days after articles are published, or sooner if spammers target a particular post. Sorry...

Commenting is not available in this section entry.