Back to Home

The clickjacking attack

The “clickjacking” attack allows an evil page to click on a “victim site” on behalf of the visitor. Many sites were hacked this way, including Twitter, Facebook, Paypal and other sites. They have all been fixed, of course.

The idea

The idea is very simple. Here’s how clickjacking was done with Facebook: 1. A visitor is lured to the evil page. It doesn’t matter how. 2. The page has a harmless-looking link on it (like “get rich now” or “click here, very funny”). 3. Over that link the evil page positions a transparent

Showing with disabled functionality

The X-Frame-Options header has a side effect. Other sites won’t be able to show our page in a frame, even if they have good reasons to do so. So there are other solutions… For instance, we can “cover” the page with a

with styles height: 100%; width: 100%;, so that it will intercept all clicks. That
is to be removed if window == top or if we figure out that we don’t need the protection. Something like this: The demo: [codetabs src=“protector”]

Samesite cookie attribute

The samesite cookie attribute can also prevent clickjacking attacks. A cookie with such attribute is only sent to a website if it’s opened directly, not via a frame, or otherwise. More information in the chapter info:cookie#samesite. If the site, such as Facebook, had samesite attribute on its authentication cookie, like this: …Then such cookie wouldn’t be sent when Facebook is open in iframe from another site. So the attack would fail. The samesite cookie attribute will not have an effect when cookies are not used. This may allow other websites to easily show our public, unauthenticated pages in iframes. However, this may also allow clickjacking attacks to work in a few limited cases. An anonymous polling website that prevents duplicate voting by checking IP addresses, for example, would still be vulnerable to clickjacking because it does not authenticate users using cookies.

Summary

Clickjacking is a way to “trick” users into clicking on a victim site without even knowing what’s happening. That’s dangerous if there are important click-activated actions. A hacker can post a link to their evil page in a message, or lure visitors to their page by some other means. There are many variations. From one perspective – the attack is “not deep”: all a hacker is doing is intercepting a single click. But from another perspective, if the hacker knows that after the click another control will appear, then they may use cunning messages to coerce the user into clicking on them as well. The attack is quite dangerous, because when we engineer the UI we usually don’t anticipate that a hacker may click on behalf of the visitor. So vulnerabilities can be found in totally unexpected places.

  • It is recommended to use X-Frame-Options: SAMEORIGIN on pages (or whole websites) which are not intended to be viewed inside frames.
  • Use a covering
    if we want to allow our pages to be shown in iframes, but still stay safe.
<style>
iframe { /* iframe from the victim site */
  width: 400px;
  height: 100px;
  position: absolute;
  top:0; left:-20px;
*!*
  opacity: 0.5; /* in real opacity:0 */
*/!*
  z-index: 1;
}
</style>

<div>Click to get rich now:</div>

<!-- The url from the victim site -->
*!*
<iframe src="/clickjacking/facebook.html"></iframe>

<button>Click here!</button>
*/!*

<div>...And you're cool (I'm a cool hacker actually)!</div>
Example:

Follow the lesson from Microsoft Web-Dev-For-Beginners course

Tags: web,development