Introduction
Since its advent in 2002, clickjacking attacks have become widespread over the years. Their stealth nature and varying techniques make them a common threat to every organization and every Internet user in general. This article will briefly describe Clickjacking, however, its main purpose is to outline some of the best protection methods against clickjacking.
Clickjacking
This is a stealth technique used by attackers to lure users into clicking an element on the web page that has multiple hidden/opaque frames on it such they may steal user's data, make them follow/like pages they do not intend to follow/like, access their webcam or in some sinister cases transfer money from their accounts. Over the Internet users have become aware of clickjacking but the downside about this form of attack is that one never realizes it when being attacked.
The most common technique is classic clickjacking where an attacker uses a hidden frame on top of an enticing page that lures the page to click it. Most common elements include popular video links, or 'CLAIM YOUR PRIZE' buttons among many other interesting features that may lure the user to click the button/link such that they may trick the user into whatever malice they intend to perpetrate. In most cases, users are not aware that they are being tricked into either transferring money or any other form of malice.
Clickjacking is a client-side attack because it uses the browsers' vulnerabilities. This being said, let's look at how best to protect your browser as well as your application from clickjacking.
Prevention
In this article, we are not going to focus on how clickjacking vulnerabilities may be exploited rather we focus on its prevention.
Browser protection
Because clickjacking is performed using the browser, it also imperative that first and foremost, we protect the tool which attackers use to perpetrate their malice. With the help of browser plugins such as NoScript and NotScript which invoke some JavaScript code that prohibits untrusted domains from performing actions on your browser. Initially, this may be annoying. However, once the user realizes the impact of clickjacking they want these plugins running. Organizations likewise should ensure or educate their users that they should make use of such tools so that the protection becomes a two-way shield against clickjacking.
Framebusting/Framebreaking/Framekiller
Organizations on the other hand have a mandate to protect their users from clickjacking and one of the first used methods was to include some JavaScript code that would block the use of frames from being included in <frames> or <iframes> by using the top.location or sometimes if not top.location in pages, they did not wish to be framed. Over time, developers discovered that attackers had devised a way to circumvent this barrier and they began to find other techniques to prevent clickjacking.
X-Frame-Options (XOF)
The X-Frame-Options HTTP Response header is one of the most commonly used defense techniques against clickjacking. It is used to determine whether a page may be embedded in a <frame>, <iframe>, or <object> element. The header comprises 3 directives that determine the page's behavior in terms of handling frames.
- DENY
To completely block all framing, but safe as it may seem this may limit the site’s functionality capabilities among many other things.
- SAMEORIGIN
Allows framing from native or pages from the same origin/domain.
- ALLOW-FROM
Allows framing from a whitelist of a given origin.
- XOF limitation is that whilst DENY and SAMEORIGIN are compatible with many browsers but ALLOW-FROM is not supported by many browsers today this means setting ALLOW-FROM in a browser that is not supported is the same as not having clickjacking protection at all thus many developers resort to using SAMEORIGIN together with Content-Security-Policy (CSP).
Content-Security-Policy (CSP)
This HTTP header was initially designed to protect against injection attack vectors as well as XSS but with its frame-ancestors directive developers can manage which origins are allowed to frame a page. Frame-ancestors can be used to allow multiple origins to frame a page which is similar to the unsupported XOF ALLOW-FROM directive. While setting the frame-ancestors directive to ‘self’ has the same implications as the XOF SAMEORIGIN directive.
The XOF DENY directive is the same as setting the frame-ancestors directive to ‘none’. Because of browser support issues, it good practice for developers to make use of both HTTP Headers to ensure security against clickjacking.
Conclusion
As mentioned earlier, it is a good practice for organizations who wish to protect their users to make use of both XOF and CSP so that they protect their users fully. The impacts of clickjacking may cost the organization's website reputation a great deal of financial loss so it is better to implement the available protection techniques to secure their users and organizational reputation.