Frame Busting
Frame busting refers to the ability of an application to avoid being encapsulated within an IFRAME. The later approach can be used to not only make one site impersonate the capabilities of another, but more sinisterly, it can be used to overlay a different user experience on top of an IFRAMEd site and allow events to flow through to the IFRAME.
Using this approach, a user can inadvertently be tricked into performing actions within an application without even knowing that they are interacting with it.
A July 2010 study by Gustav Rydstedt, Elie Bursztein and Dan Boneh of Stanford University and Collin Jackson of Carnegie Mellon University named: "Busting Frame Busting: A Study of Clickjacking Vulnerabilities on Popular Sites", explores the risks and problems associated with framing. It can be found here:
http://seclab.stanford.edu/websec/framebusting/
The study mentioned above forms the basis of the following case study.
Frame busting defense
The defenses we will introduce in this case study are rather simple; we will add some JavaScript and a few extra HTTP headers to the logon page of the Qwerty app. Depending upon the application, it may also be relevant to add this code to other pages, but for now we will just select the logon page for simplicity.
The JavaScript we will add looks as follows:
The above script has been placed in the public domain by the authors of the study.
In simple terms, it sets the entire page invisible through use of a CSS directive and only makes it visible if the page itself is the top frame and JavaScript is enabled.
In addition to the above code, we will add a couple of HTTP Headers that take advantage of built in frame busting defenses in certain browsers. The headers to set are as follows:
Planning the rules
The rules required for this case study are extremely simple. Our plan is to:
Determine whether we are on the logon page.
If yes, add the frame busting code.
Getting started
The very first step as always is to create a repository. In this case we will name it "Frame Busting Example".
Once done, copy and paste the JavaScript code into a text file named "framebust.js" and upload it to the data folder in the repository.
Then create a new blank rule set named "FrameBust".
Creating the rules
The first rules we need simply determine if we are on the logon page:
These rules are the same as in most of our other examples, so we will just list the properties here for quick reference:
Once the properties are set, simply add a chainpoint to the Switch rule and name it "logon.jsp".
We next add the rules to inject the JavaScript and headers:
We read the frambust.js file into a variable, we then set a couple of variables to the header values we need, and finally we add the JavaScript and headers to our response. The properties look as follows:
Values are: SAMEORIGIN,allow *; frame-ancestors 'self'
Header field names are: X-FRAME-OPTIONS,X-Content-Security-Policy
That is it, save the rule set and create a configuration to test it.
Creating the configuration
The configuration for this rule set is very simple, we create one named "FrameBustTest". The following shows the relevant sections that need to be defined:
Testing
Qwerty is a suitable test application for this case study because it uses frames to encapsulate the logon and other internal pages.
When navigating to Qwerty landing page URL in the browser you will see is as follows:
To test the new rule set, deploy the configuration to the Qwerty demo server and start it. Then refresh the Qwerty logon page.
Whilst you will not see any visual differences in the appearance of the Qwerty application, the Qwerty landing page URL in the browser will now look like this:
http://localhost/qwerty/logon.jsp
We can proceed to navigate to other pages in the Qwerty application outside of the main Qwerty frame.
For example, these pages would normally all be loaded from within the Qwerty frame, but are now visible in the main browser address bar:
We have successfully "Busted" out of the frame.
Last updated
