Should I prevent user from operating with site during some first seconds?

Question

Imagine the following scenario: User is at attacker.com and plays a game there. Just before he clicks at some point he is rerouted to victim.com using browser's history. User thought that he clicked at attacker.com but really he clicked at victim.com thus involving undesired operation. See demonstration of it at http://lcamtuf.coredump.cx/clickit/.

How can owner of victim.com protect from such attacks? And should he?

Answer 1

Zalewski's navigate-into and navigate-away attacks are based on navigation without unfocusing the window; especially in the smoothest case where the ‘back’ operation triggers the bfcache, you are unlikely to even get an onblur or onfocus event!

These can be countered by detecting that your window has been opened by a script. This can be done by checking for window.opener; window.name is also worth looking for, since a named window can potentially be ‘found’ by window.open.

This would typically be added to a frame-breaker script, eg:

if (top!==self || opener!==null || name!=='') {
    // countermeasure
}

where the countermeasure would be something like hiding/inactivating the whole page content (not navigate-top as this is really easy to stop).

As with framebreakers in general this requires JavaScript so won't work if it's disabled and could potentially be attacked via IE's bogus anti-XSS filter (if you have not disabled it with X-XSS-Protection). If you are an application that relies on JS and doesn't need HTML-only accessibility you can default-deny here for more reliability.

Naturally if you do this, you or your partners can't open your page in a pop-up either.

There are other similar attacks involving closing tabs or pop-ups to cause your page's content to appear under the pointer, but they are less smooth than the navigate-variety attacks. In these cases you do get onfocus/onblur and it is reasonable to react by making the interface inactive for a period after an onfocus if there is a page you're particularly concerned about protecting.

A general mitigation for the whole class of vulnerabilities would be not to make any dangerous operation proceed from a single click on a page that may be directly navigated to. This sounds weak, but you will probably find you're already doing that naturally in many cases for non-security reasons, eg Delete Account -> “Are you sure you wish to permanently delete your account?”.

Answer 2

In theory, the website operator can prevent such attacks by using window onfocus and onblur events. For example, on window onfocus event one could create a <div> overlay over whole page for half a second, thus preventing interaction with page elements. I didn't see that in use anywhere though, and I don't suspect it will gain popularity as it will probably be bypassable anyway.

The attack you describe, created by Michael Zalewski is just one of many proof-of-concept novelty attacks demonstrating why 'the web is broken' at a fundamental level. Some of his previous attacks based on timing - HTML5 geolocation consent hijack - exploited similar vector and has been fixed at a browser level. One would suspect this class of vulnerabilities will be fixed in browsers in the (possibly far) future, but they are very tricky to fix as they exploit human imperfections that may manifest in various ways.

Long story short: You could try to experiment with onfocus and onblur events, but be prepared for browser quirks and don't spend too much time over it. It's unlikely to be massively abused by black hats.