New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users

Issue metadata

Status: WontFix
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Sign in to add a comment

Security: Visited links can be detected via redraw timing

Reported by, Jun 20 2013 Back to list

Issue description

It's possible for a web page to tell if a link is visited by detecting the redraw that occurs when the link colour changes. The method works as follows:

Place a number of <a> elements on the web page, with hrefs we know aren't visited. Then update the hrefs to point to a URL we want to check. If the URL is visited the <a> elements will be redrawn as :visited. After updating the link elements, the web page can use requestAnimationFrame to time how long the next frame takes to draw. By using a large number of links and by making the links slow to draw (e.g. by setting a large text-shadow), the redraw (if it occurs) will delay the next frame and will be detectable.

A slight trick is required to make the links repaint. Simply updating the href of a link won't cause it to be repainted if the visited-ness has changed. 'Touching' the style of each link (e.g.'red';'';),will force Chrome tore-check the styles and repaint if necessary.

Chrome Version: [27.0.1453.116 m] + [29.0.1542.0 canary]
Operating System: [Win 7 SP1]

The attached PoC shows this in action. On my PC it can currently check about 20 URL/sec but I believe this could be increased somewhat (e.g. by testing 4000 different URLs in one go, if a repaint is detected, do a binary chop and test each half separately, then continue down to single URLs)


Comment 2 by, Jun 20 2013

Attachment was broken before, correct one is attached.
7.2 KB View Download
Labels: Security_Impact-Beta Security_Impact-Stable M-27
Status: Assigned
Thanks for the report, interesting. A clever idea. I wonder if this can be mitigated at all or if it's hopeless.

@mkwst: could you collect the privacy team's thoughts on this? I'm not going to assign a severity yet.

Comment 4 by, Jun 22 2013

Without the trick that forces the re-style, this wouldn't work. If Chrome never changed the 'visited' state of a link once it has been created then it would prevent this particular attack.

The other option would be to always repaint the link if the href changes, even if the visited state doesn't change.

Comment 5 by, Jun 28 2013

I will be talking about this issue and similar ones in IE and Firefox next month at Black Hat. 

Mozilla have rated this as a low impact security/privacy issue, and I don't believe that disclosing it will put users at any significant risk. It's effectively equivalent to the CSS history sniffing attack that was present in all browsers for over 10 years, though being a timing attack it is not as speedy as the original technique and its accuracy is dependent on how much load a machine is under.
Labels: Security_Severity-Low
Assigning severity label.
Labels: Cr-Blink
Labels: -Restrict-View-SecurityTeam -Security_Impact-Beta -Security_Impact-Stable -Security_Severity-Low
Removing erroneously assigned labels and making the bug public since it was already discussed at Blackhat:

Comment 9 by, Aug 27 2013

Labels: OS-All
Labels: -M-27 Pri-2 Security_Severity-Low Security_Impact-Beta Security_Impact-Stable
Flagging for now as severity low, but no idea what we'll do about it.
Project Member

Comment 11 by ClusterFuzz, Sep 26 2013

Labels: M-29
Project Member

Comment 12 by ClusterFuzz, Oct 1 2013

Labels: -M-29 M-30
Fixing milestone and impact labels.

Comment 13 by, Nov 12 2013

Labels: Cr-Privacy
Labelling as privacy relevant, because this partly leaks browsing history.
Project Member

Comment 14 by ClusterFuzz, Nov 13 2013

Labels: -M-30 M-31
Migrating old milestone labels.

Comment 15 Deleted

Removing milestones from low severity security issues. If you are actively working on this bug, then please add a milestone explicitly.
Labels: -M-31
Removing milestones from low severity security issues. If you are actively working on this bug, then please add a milestone explicitly.
Ping! Can we fix this bug?

Firefox seems too slow for the attack to succeed, but it still works well and reliably on Chrome.
The last time we looked into this, the conclusion was that the only useful way of mitigating this class of attacks (double-keying visited link history) will impact usability (you'd only see the link as visited if you visited it from this site).

I'd say it's won't fix
Do you think double-keying is a serious usability issue? My assumption would be that users typically navigate to sites through the same access paths. E.g. from a search engine to the site. From Facebook to the site, etc..
well, as soon as you use facebook and reddit, it's broken, because you don't see which links you've already visited via the other path.
Status: WontFix
Closing this as WontFix based on comments 19 and 21. Feel free to reopen if you think there should be additional discussion here.
I am wondering why the solution of comment 4 is not considered: "to always repaint the link if the href changes, even if the visited state doesn't change."? This would mitigate the attack completely.

Firefox has a similar bug report:
Chrome has synchronised history lookup queries, and the link style is only altered after the href is changed (after its initial change). Proposed solution: do a restyle when href is changed regardless of whether links are visited

This would prevent the loss of user friendliness; additionally, the efficiency loss in normal browsing situations would be negligible.

Unless I am missing something? I am not familiar with the Chromium implementation.
 Issue 577966  has been merged into this issue.

Comment 25 by, Jan 15 2016

Why not just add stroke and fill to the blacklist of CSS properties that can be affected by :visited?

Sure, it means some sites will have to update, but the same was true of sites that previously used e.g. background images as a visited link indicator.
While that might work for the specific method used in  issue 577966 , I don't see how that approach would solve the problem in general. It seems like this might be a losing game of whack-a-mole :-(

Comment 27 Deleted

Why not just add random time penalties for anything causing repaints because of :visited?
I'm not familiar enough with rendering to judge how practical that is, but adding random delays does not typically prevent timing attacks - it can usually defeated by taking a large number of measurements and applying statistics.

Comment 30 by, Jan 15 2016

Regarding #25, I'd rather suggest using a *white*list of properties that can be safely applied to :visited anchors, so they don't imply any meaningful change in rendering times. For example, text colors, background colors or border styles, but not, for example, any width, positioning or properties like box-shadow, which would be inherited from the normal state.
That would seriously limit the styles that could be applied to :visited links, but after all they should be stylized for a semantic reason, not aesthetic.
Project Member

Comment 31 by ClusterFuzz, Feb 2 2016

Labels: -Security_Impact-Beta
Project Member

Comment 32 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 33 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic

Sign in to add a comment