Framebusting - The Dual Protection Core

Since the outcome of ClickJacking attacks, framebusting has become the unavoidable part of web application security. Considering the real world scenario, it has been noticed that still the appropriate protections have not been placed in the plethora of websites. Seclab guys conducted the study on framebusting. They raise a point on the right way of implementing the framebusting code. However, a similar protection features have been implemented in the famous websites such as Twitter, Facebook etc. However, my personal opinion is to use the dual protection which includes the implementation of declarative security as well as framebusting code. No doubt, only new versions of certain browsers such as Internet Explorer, Firefox etc support some of the declarative security features. Deploying declarative security feature is a good additional point. I have written Firefox addons that detect the presence of declarative security headers that are coming from servers. In this post, I am using X-Frame-Options detector hosted here

Lets see how the twitter implements the framebusting code

========================= TWITTER ======================================
function bust () {
document.write = "";
window.top.location = window.self.location;
setTimeout(function() {
document.body.innerHTML = '';
}, 0);
window.self.onload = function(evt) {
document.body.innerHTML = '';
};
}
if (window.top !== window.self) { // are you trying to put self in an iframe?
try {
if (window.top.location.host) { // this is illegal to access unless you share a non-spoofable document domain
// fun times
} else {
bust(); // chrome executes this
}
} catch (ex) {
bust(); // everyone executes this
}
}
========================= TWITTER =====================================

This works very well. The beauty of this protection is even if the webpage is framed using advanced techniques, the twitter displays the white page thereby dethroning the success rate of successfully framed web page. Give a shot yourself. Apart from this, twitter also throws X-Frame-Options header which adds another protection layer to use the inbuilt browser protection mechanism



Let's have a look at the Facebook

========================= FACEBOOK ==============================

function si_cj(m)
{
setTimeout(function()
{
new Image().src="http:\/\/error.facebook.com\/common\/scribe_endpoint.php?c=si_clickjacking&t=8340"+"&m="+m;
},5000);
}
if(top!=self)
{try{if(parent!=top)
{throw 1;}var si_cj_d=["apps.facebook.com","\/pages\/","apps.beta.facebook.com"];

var href=top.location.href.toLowerCase();

for(var i=0;i<si_cj_d.length;i++)

{if (href.indexOf(si_cj_d[i])>=0){throw 1;}}si_cj("3 ");}

catch(e){si_cj("1 \t");window.document.write("\u003cstyle>body * {display:none !important;}\u003c\/style>\u003ca href=\"#\" onclick=\"top.location.href=window.location.href\" style=\"display:block !
important;padding:10px\">\u003ci class=\"img sp_8lnh2w sx_fcd3c0\" style=\"display:block !important\">\u003c\/i>Go to Facebook.com\u003c\/a>");
}}

============================ FACEBOOK ==============================

This code works appropriately and displays the small Facebook image with a link to main Facebook page in the Iframe as presented below



Facebook does not use declarative security protection feature



Google implements the code as follows

if (top.location != self.location) {top.location = self.location.href;}

It also implements the X-Frames-Options header to add another layer.



The cases discussed above are from the most explored websites. However, the normal scenarios are very bad. My suggestion is to implement both solutions collaboratively rather than sticking to one. The browser security guys are implementing inbuilt solutions and we should harness the power. The dual protection is always good.