Introduction
The severity of clickjacking attacks is mainly based on the stealthy nature of the technique. This prompted developers and researchers across the globe to discover a solution to protect organizations and users from the impacts of the attack vector. One of the most recommended protection techniques was frame busting. In its first introduction, the protection method was a simple JavaScript conditional block that checked if the 'top. location’ was the legit page and did not exist in any frame if not the block would simply set the legit web to be the top page thus removing the frame and saving the day like. ‘top.location=self.location’.
At one time, developers thought the problem was solved, but then they realized that attackers could easily circumvent this Javascript conditional block using various methods, including the use of the 'OnBeforeUnload' event handler, double framing, and various other methods that were devised to bypass/bust frame busting. This would leave users exposed to risk and multiple threats until mechanisms and techniques were introduced to protect users and organizations against frame-busting busters. This article will describe some possible ways users may protect themselves from frame-busting busters.
X-Frame-Options (XFO) HTTP Header
One of the ways organizations can protect their users from clickjacking malice and framebusting busters is through the use of HTTP response header X-frame-Options (XFO) which consists of 3 directives to regulate the behavior of web pages with regards to accepting frames or being framed. The XFO has three directives namely ‘DENY’, ‘SAMEORIGIN’, and ‘ALLOW-FROM uri’ which control the web page from being framed depending on the directive used by the developer.
Deny
This directive blocks the web page from being framed by any other page, which in business terms limits the page's functionality. Generally, any webpage has to interact with other safe pages on the internet to promote its visibility and functionality. However, this directive may be used if the organization is certain that its web page will not require any framing at all.
SAMEORIGIN
This directive will accept the web page to be framed but only sites from the same origin as the web page. This allows organizations to restrict the page to be framed by websites from their sub-domains only. Most organizations that use XFO would prefer to use this directive on their pages.
ALLOW-FROM (URI)
This directive is meant to allow the web page to be framed by specific websites from the specified origin or given URI. Unfortunately, most browsers do not support this directive as of yet. This means setting your page to this directive might leave your users still exposed to clickjacking.
XFO has its limitations which include browser support and also W3C has not yet accepted it as an International Standard but most organizations are slowly moving towards implementing it due to the continued framebusting busters.
Content-Security-Policy
- This is another HTTP response Header that may be used to prevent the bypassing of framebusting JavaScript code. The policy has a directive similar to that of XFO called ‘frame-ancestors’. By setting the directive frame-ancestors=’none’ equivalent to the XFO’s ‘DENY’ directive which blocks or disallows any framing of the page.
- The frame-ancestors directive may also be set to ‘self’’ which allows framing from websites of the same origin similar to the XFO’s ‘SAMEORIGIN’ directive.
- You can also whitelist the allowed URIs using the frame-ancestors directive to define which sites will be allowed to frame your page.
- It is advisable to use both of these headers to make your pages more secure.
JavaScript Protection
After a close assessment, some organizations still depend on the framebusting technique but have only improved it. Instead of using the HTTP response Headers or the old simple conditional JavaScript code they put into consideration HTML5 standards like Sandboxing and have come up with a possible solution to deal with the busting of framebusting. The idea is clearly revealed in this link.
The JavaScript code snippet to bust frame busting according to Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson (2010) is as follows.
<style id="antiClickjack">
body {
display: none !important;
}
</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
According to the authors of the script, the page will remain blank if JavaScript is disabled in the browser or it will make an attempt to framebust. The page cannot be used if the user has JavaScript disabled. Although this may sound assuring, the author reserves the qualification of this script to be reliable to the user of the script.
Conclusion
Although the use of HTTP response Headers has not become that popular but it seems to be a safer technique to protect organizations from busting framebusters. The use of both Headers is advisable for stronger protection. It is not good security practice to implement methods that are not yet proven to be reliable and developers may use the JavaScript option if they have confirmed and tested that it works well in their business environment.
References