Clickjacking in Plain English
By- October 23, 2014
In another blog post, I discussed a vulnerability called Cross-Site Request Forgery (CSRF) that allows an attacker to force a victim to perform actions on their logged-in sites inadvertently. The defense I recommended was called the Synchronizer Token Pattern, as the defense relies on using randomly-generated tokens to which attackers would not have access. Hackers are both clever and resourceful, however, and if your website is vulnerable to a technique called clickjacking, attackers can force victims of your site to perform unwanted actions even if proper CSRF protections are in place.
This attack is best understood visually. Let’s suppose, only for illustration, that eBay is vulnerable to clickjacking—meaning that an attacker could embed an eBay page in an iframe on their own site. A product listing page looks like the following.
An attacker can construct a website that contains a really enticing button, just begging to be clicked.
Then, they can precisely overlay the eBay iframe so that the “Buy It Now” button sits perfectly on top of the “FREE” button. The following uses a semi-transparent iframe for illustration purposes.
Lastly, they can make the iframe invisible, yet still technically “on top of” the site’s content, so when the user thinks they’ve just clicked on a link, they actually became proud owners of a new car.
In the above example, an attacker can trick an unsuspecting user into buying a Ford. Even if the “Buy It Now” button is inside of a CSRF-protected form, the request goes through, the website has no way to distinguish an intentional click from one contrived by an attacker. This same attack can be used to cause the user harm, such as tricking them into deleting all of their emails by lining up the “Delete All” button under the “FREE” button. An attacker could also trick the user into opening themselves up to further attack by disabling defenses and enabling your webcam. If that’s not scary enough, or you already cover your webcam with black tape, an attacker can construct a precise combination of malicious text fields and buttons and trick a victim into resetting their password for another service.
To prevent this attack, you need to prevent the ability for your site to be embedded as a frame in another site. There are two ways to solve this. In short, there is the established way and the new way. Since we’re in the middle of a transition phase—the new way is still very new and not widely supported—I recommend doing both, to prepare yourself for the inevitable day when the old way is deprecated.
The Established Way
The common way this is done is by adding an HTTP header that serves just this purpose:
X-Frame-Options. As you may know, the
X- prefix indicates that this is a non-standard header; however, this header is understood by all major browsers, including Chrome, Safari, Opera, Firefox, and Internet Explorer 8 and newer. Browsers refuse to load content in an iframe if that content includes this header and the header disallows it. The header has two possible values:
DENY is self-explanatory, and
SAMEORIGIN allows the page to be embedded only within the same domain as the embedding site. There does exist a third option called
ALLOW-FROM uri, but neither Chrome nor Safari plan to support it. Therefore, I do not recommend using
ALLOW-FROM at all.
The New Way
There’s a new all-encompassing HTTP header that’s on its way to becoming a standard. It’s called
Content-Security-Policy (CSP). The
frame-ancestors, a whitelist of trusted sources that are allowed to include your page in a frame.
If you want to prevent framing of your page entirely, use the CSP header like this:
Content-Security-Policy: frame-ancestors 'none'
To allow framing only within your own site, you can replace
'self'. Alternatively, you can supply a list of allowed, trusted domains. Like all aspects of CSP, it’s very flexible.
Content-Security-Policy: frame-ancestors tinfoilsecurity.com example.com
You can use an automated web security scanner like Tinfoil to crawl your site and ensure that no page is vulnerable to clickjacking. Tinfoil provides the best web application security solution on the market, and it detects clickjacking vulnerabilities on your website along with many other types of web vulnerabilities.