# 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 <a href="#toc492971249" id="toc492971249"></a>

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:

```html
<style>
html { visibility : hidden;}
</style>

<script>
if (self == top) {
document.documentElement.style.visibility='visible';
} else {
top.location=self.location;
}
</script>
```

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:

```json
X-FRAME-OPTIONS: SAMEORIGIN
X-Content-Security-Policy: allow *; frame-ancestors 'self'
```

## Planning the rules <a href="#toc492971250" id="toc492971250"></a>

The rules required for this case study are extremely simple. Our plan is to:

1. Determine whether we are on the logon page.
2. If yes, add the **frame busting** code.

## Getting started <a href="#toc63080418" id="toc63080418"></a>

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 <a href="#toc492971251" id="toc492971251"></a>

The first rules we need simply determine if we are on the logon page:

![FrameBust rule set](https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-718d7060a6ae7dbd495606657353df61565715d0%2F1.jpeg?alt=media)

These rules are the same as in most of our other examples, so we will just list the properties here for quick reference:

<figure><img src="https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-3e7c53f4cb54d2adf31b698b1417aca6d1dd7c87%2Fimage.png?alt=media" alt=""><figcaption><p>Name Splitter properties</p></figcaption></figure>

<figure><img src="https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-f27775a46479c98f015d7c193d3fb783f902725a%2Fimage.png?alt=media" alt=""><figcaption><p>Switch properties</p></figcaption></figure>

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:

![FrameBust rule set](https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-66692deba70d8fce42771f22a13326cccc027c1a%2F4.jpeg?alt=media)

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:

<figure><img src="https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-a42147b4ed8a9e32b5a05848ca652c77d7f857d6%2Fimage.png?alt=media" alt=""><figcaption><p>File Reader properties</p></figcaption></figure>

<figure><img src="https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-f16356123a4d1e18c0e9265dd6f53c0d45140622%2Fimage.png?alt=media" alt=""><figcaption><p>Set Variables properties</p></figcaption></figure>

Values are: SAMEORIGIN,allow \*; frame-ancestors 'self'

<figure><img src="https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-bca7ec05b385db423a62365c61446fff8f5126e7%2Fimage.png?alt=media" alt=""><figcaption><p>HTTP Response Addition properties</p></figcaption></figure>

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 <a href="#toc492971252" id="toc492971252"></a>

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:

![Create new Configuration, general tab](https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-64daa07fdf5457f5a61f262722eaef3560fcafcb%2F8.jpeg?alt=media)

<figure><img src="https://2423451286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F42mDa58RoaDxb6t8mbaI%2Fuploads%2Fgit-blob-6605b479887ab381809a649a04d93b79146f7229%2Fimage.png?alt=media" alt=""><figcaption><p>Input source tab</p></figcaption></figure>

## Testing <a href="#toc492971253" id="toc492971253"></a>

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:

<http://localhost/qwerty/>

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:

* <http://localhost/qwerty/main.jsp>
* <http://localhost/qwerty/setup.jsp>
* <http://localhost/qwerty/pay.jsp>

We have successfully "Busted" out of the frame.
