A User Interface Redressing Attack, also known as Clickjacking, describes a user being tricked into clicking a webpage element which is disguised as another element or even invisible.
A popular example is the redressing of a Like-Button of a social network: An attacker creates a website with a button that attracts the user to click it, e.g. by offering premium content or participation in a lottery. The attacker now adds another page with a Like-Button of a social network to the original page by using a mechanism called iframe. Then he turns the iframe invisible by making it fully transparent. Finally, he places the now invisible Like-Button in the iframe over the attractive button. The Result: An unsuspecting user thinks he has clicked the original button, but instead he clicked the invisible Like-Button. Hence, the attacker successfully gained a like by fraud.
The whole technique is based on the incorporation of the invisible iframe, which contains a button or another actionable item. The attacker only needs some basic knowledge of HTML and CSS to pull off the trick. In our example we described an approach also called Likejacking, however there are many more variants of clickjacking like CookieJacking or FileJacking. Nevertheless, they all apply the same modus operandi: trick the user by manipulating the User Interface, in a more technical language: by redressing the User Interface.
There are two client-side mechanisms to prevent those type of attacks: the older X-Frame-Options and the newer Content-Security-Policy header. Both HTTP headers work in a similar way. They tell the browser in which other site a website may be shown in. They can deny this behavior all together, so no other website can show the website within an iframe. Furthermore, they can allow a website to be shown in itself or can specify those websites which are allowed to show the site in a frame or iframe. For the best protection both headers should be used with most restricting settings.
What is a "good" HTTP-Header configuration for your website? In terms of clickjacking protection you need to disable the functionality, that third-party websites are able to embed your website and present it under a different domain name. The most simple variant is to limit your website to your own domain.
Due to the historic security improvements in browser security, you need to configure two different settings in order to protect all your website visitors, that are users of legacy browsers and users of modern browsers:
Set the following HTTP-Header to completely disable the embed possibility of your website for third-party web-servers on legacy browsers. This should be fine for most websites:
We recommend not using any of the other X-Frame-Options header settings, since all of them will fail in an insecure fashion in some configuration. The X-Frame-Options header should really only be used in addition to a Content-Security-Policy header. It then serves the purpose to protect legacy browsers which still do not support Content-Security-Policy, which is an ever decreasing minority of browsers.
In order to protect website visitors with modern browsers the same way you did for website visitors with legacy browsers (to completely disable the embed possibility of your website for third-party web-servers), you need to set the following HTTP-Headers:
Alternatively you can limit it via Content-Security-Policies to your own domain:
The Mozilla Developer Network has detailed instructions how to set these for the most common web-servers.
Using the following setting and listing Fully-Qualified Domain Names (FQDN) for
frame-ancestors is also acceptable, if the referred website is allowed to show your site within a frame: