NB: This is the eighth post in a series of posts on web application security.
Click-jacking is a process of “stealing” clicks on your site, redirecting them to other places, either by using an XSS vector to replace the targets of links (or whole sections of the page) or by putting your page in an
iframe and placing the attacker’s content over yours. The idea is to make this look as seamless as possible, so the user can’t tell right away that something is wrong.
Click-jacking is a bit of a red-headed stepchild of security vulnerabilities. Usually, there’s just not a lot of value in it. Where it is valuable is ads and phishing schemes.
For ads, if someone can frame your site, place their own ads over yours, and keep people from noticing, then all your ad revenue goes to them. Literally stealing.
Worse, if someone frames your site and puts login controls directly over yours, then even tools like SiteKey (which doesn’t work very well, anyway) won’t prevent them from collecting username and password data.
This is an arms race of frame-busting tools and anti-frame-busting tools, but now browsers are helping.
The X-Frame-Options header tells the browser what, if anything, is allowed to frame the current content. The interesting values are
SAMEORIGIN. For most use cases, you probably want to send
DENY on every response, or maybe
SAMEORIGIN. Just to be on the safe side.
Django has tools for this since 1.4. Use them.
X-Frame-Options isn’t perfect, especially because it doesn’t help users with old browsers. Maybe that’s OK, given your browser support matrix, or maybe it’s just a starting point, but it’s a good starting point. Another lock on your door.
Especially when it comes to the phishing side of this, we enter the realm of social engineering. In our dream world, users look at the location bar in the browser before entering any important info—or at least they always use a bookmark or other consistent, hard-coded access method.
But in the real world, there are domains like
twiiter.com, and Unicode domains that use characters that look the same, and favicons that are locks. And users barely even look at the location bar, anyway.
I dearly wish I knew how to fix that. Browsers are trying, by highlighting the domain in the location bar, by moving favicons out of it (though moving things around probably doesn’t help). Unfortunately, social engineering will probably always be one of the easiest and most common ways of exploiting any system you can invent.
Maybe browsers can do more? There is already the Safe Browsing API that Google provides, and many browsers implement, though that relies on use reports and is largely reactive. Maybe user agents can start looking at domain names and if it seems too similar to a domain you regularly visit, it can pop up a warning of its own?
What else do you think browsers could do to help?