The word “clickjacking” might conjure an image of some dangerous species lurking in the shadows at night in the jungles of an unexplored continent, or perhaps an image of “carjackers” in the urban jungle. In reality, those descriptions aren’t too far off, except that instead of a jungle, we’re talking about the dense and complex network of the web. So, what is clickjacking, and how can you prevent it?
OWASP offers a good example of a clickjacking attack:
…imagine an attacker who builds a web site that has a button on it that says “click here for a free iPod”. However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the “delete all messages” button directly on top of the “free iPod” button. The victim tries to click on the “free iPod” button but instead actually clicked on the invisible “delete all messages” button. In essence, the attacker has “hijacked” the user’s click, hence the name “Clickjacking”.
If you were the manager of the website with the “delete all messages” link that was invisibly framed above, you would want a way to prevent such an attack, right?
Going Head First
In a prior blog post we discussed the importance of using HTTPS on all of your organization’s websites, and the use of an HTTP header called HTTP Strict Transport Security (HSTS) to help ensure that the communications between your website visitors and your servers are safe.
An HTTP header is a bit of communication that gets sent by a server to your browser (Chrome, Firefox, Internet Explorer, or Safari) to help it properly display the page you want to view. HTTP headers offer great opportunities for improving security because the level of effort to implement them is usually low and the protection they offer is strong.
Now let’s look at another HTTP header that can help keep your website from being compromised.
The term “X-Frame-Options” isn’t nearly as exotic-sounding as “clickjacking”. It sounds like a poorly named robot in a bad science fiction movie. Despite its sci-fi name, we recommend you implement X-Frame-Options on your organization’s website, because it virtually guarantees that clickjacking attacks won’t work against it.
Don’t just take our word for it. As noted web application security guru Robert Hansen tweeted at last year’s BlackHat conference:
Quick note: if you aren’t using X-Frame-Options on your website you may want to start. Like, pronto. As in now. #Blackhat
— RSnake (@RSnake) August 1, 2013
There are multiple ways X-Frame-Options can be implemented. The two most popular are X-Frame-Options: Deny and X-Frame-Options: SameOrigin.
We’ll leave it to the experts at your organization to determine which implementation is best for you. Whatever happens though, if they mention the words “frame busting” or “frame busters”, please remind them that this is 2014. As Troy Hunt put it:
Frame busters are hacks. Nasty, messy hacks of limited efficiency. What we really need is a simpler, more semantic means of specifying how and where a page may be used when it comes to being embedded in a frame and that’s what we have in the X-Frame-Options (XFO) header.
If you need another resource to help guide your team in getting X-Frame-Options up and running, this post by Eric Lawson is a sound starting point. Lawson is responsible for creating this HTTP header while working at Microsoft.
Tired of reading? This recent video from Google’s Mike West makes XFO crystal clear.
If you have any questions, feel free to contact us.