Difference between revisions of "Clickjacking Defense Cheat Sheet"

From OWASP
Jump to: navigation, search
m (Improved flow)
(Update Browser Support and other cleanup)
Line 1: Line 1:
 
= Clickjacking Defense Introduction =
 
= Clickjacking Defense Introduction =
  
This cheat sheet is focused on providing developer guidance on Clickjack/UI Redress attack prevention. For more information on the risk of Clickjacking, please visit [https://www.owasp.org/index.php/Clickjacking this page]. Additional references on clickjacking can be found [https://www.owasp.org/index.php/Clickjacking#References here].
+
This cheat sheet is focused on providing developer guidance on Clickjack/UI Redress attack prevention. For more information on the risk of Clickjacking, please visit [https://www.owasp.org/index.php/Clickjacking this page]. Additional references on Clickjacking can be found [https://www.owasp.org/index.php/Clickjacking#References here].
  
The most popular way to defend against clickjacking is to include some sort of "frame-breaking" functionality which prevents other web pages from framing the site you wish to defend. This cheat sheet will discuss two methods of implementing frame-breaking: first is X-FRAME-OPTIONS headers (used if the browser supports the functionality); and second is javascript frame-breaking code.
+
The most popular way to defend against Clickjacking is to include some sort of "frame-breaking" functionality which prevents other web pages from framing the site you wish to defend. This cheat sheet will discuss two methods of implementing frame-breaking: first is X-Frame-Options headers (used if the browser supports the functionality); and second is javascript frame-breaking code.
  
= Defending with X-FRAME-OPTIONS response headers =
+
= Defending with X-Frame-Options response headers =
  
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
+
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites.
  
=== X-FRAME-OPTIONS Header Types  ===
+
=== X-Frame-Options Header Types  ===
  
There are three types of X-FRAME-OPTIONS headers.
+
There are three possible values for the X-Frame-Options headers:
* The first is X-FRAME-OPTIONS <b>DENY</b>, which prevents any domain from framing the content.
+
* <b>DENY</b>, which prevents any domain from framing the content.
* The second option is X-FRAME-OPTIONS <b>SAMEORIGIN</b>, which only allows the current site to frame the content.
+
* <b>SAMEORIGIN</b>, which only allows the current site to frame the content.
* The third, is the X-FRAME-OPTIONS <b>ALLOW-FROM</b> 'sitename' header, which permits the specified 'sitename' to frame this page. (e.g., ALLOW-FROM http&#58;//www.foo.com) The ALLOW-FROM option is a relatively recent addition (circa 2012) and may not be supported by all browsers yet.
+
* <b>ALLOW-FROM uri</b>, which permits the specified 'uri' to frame this page. (e.g., ALLOW-FROM http&#58;//www.example.com) The ALLOW-FROM option is a relatively recent addition (circa 2012) and may not be supported by all browsers yet.
  
 
=== Browser Support ===
 
=== Browser Support ===
  
The following browsers support X-FRAME-OPTIONS headers.
+
The following browsers support X-Frame-Options headers.
  
 
<table border="1">
 
<table border="1">
<tr> <th>Browser</th> <th>Lowest version</th></tr>
+
<tr> <th>Browser</th> <th>DENY/SAMEORIGIN Support Introduced</th> <th>ALLOW-FROM Support Introduced</th></tr>
<tr> <td>Internet Explorer</td> <td>8.0</td></tr>
+
<tr> <td>Chrome</td> <td>4.1.249.1042</td> <td></td> </tr>
<tr> <td>Firefox (Gecko)</td> <td>3.6.9 (1.9.2.9)</td></tr>
+
<tr> <td>Firefox (Gecko)</td> <td>3.6.9 (1.9.2.9)</td> <td>[https://bugzilla.mozilla.org/show_bug.cgi?id=690168 18.0]</td></tr>
<tr> <td>Opera</td> <td>10.50</td> </tr> <tr> <td>Safari</td> <td>4.0</td></tr>
+
<tr> <td>Internet Explorer</td> <td>8.0</td> <td></td> </tr>
<tr> <td>Chrome</td> <td>4.1.249.1042</td> </tr>
+
<tr> <td>Opera</td> <td>10.50</td> <td></td> </tr>
 +
<tr> <td>Safari</td> <td>4.0</td><td>[https://bugs.webkit.org/show_bug.cgi?id=94836 Not supported/Bug reported]</td> </tr>
 
</table>
 
</table>
  
Reference: [https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header]
+
References:  
 +
* [https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options Mozilla Developer Network]<br>
 +
* [http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ IETF Draft]
  
 
=== Implementation ===
 
=== Implementation ===
Line 40: Line 43:
 
=== Limitations ===
 
=== Limitations ===
  
* '''Per-page policy specifcation'''  
+
* '''Per-page policy specification'''  
The policy needs to be specifed for every page, which can complicate deployment. Providing the ability to enforce it for the entire site, at login time for instance, could simplify adoption.
+
The policy needs to be specified for every page, which can complicate deployment. Providing the ability to enforce it for the entire site, at login time for instance, could simplify adoption.
  
 
* '''Problems with multi-domain sites'''
 
* '''Problems with multi-domain sites'''
Line 47: Line 50:
  
 
* '''Proxies'''
 
* '''Proxies'''
Web proxies are notorious for adding and stripping headers. If a web proxy strips the X-FRAME-OPTIONS header then the site loses its framing protection.
+
Web proxies are notorious for adding and stripping headers. If a web proxy strips the X-Frame-Options header then the site loses its framing protection.
  
 
= Clickjacking defense for legacy browsers =
 
= Clickjacking defense for legacy browsers =

Revision as of 07:12, 3 April 2013

Contents

Clickjacking Defense Introduction

This cheat sheet is focused on providing developer guidance on Clickjack/UI Redress attack prevention. For more information on the risk of Clickjacking, please visit this page. Additional references on Clickjacking can be found here.

The most popular way to defend against Clickjacking is to include some sort of "frame-breaking" functionality which prevents other web pages from framing the site you wish to defend. This cheat sheet will discuss two methods of implementing frame-breaking: first is X-Frame-Options headers (used if the browser supports the functionality); and second is javascript frame-breaking code.

Defending with X-Frame-Options response headers

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites.

X-Frame-Options Header Types

There are three possible values for the X-Frame-Options headers:

  • DENY, which prevents any domain from framing the content.
  • SAMEORIGIN, which only allows the current site to frame the content.
  • ALLOW-FROM uri, which permits the specified 'uri' to frame this page. (e.g., ALLOW-FROM http://www.example.com) The ALLOW-FROM option is a relatively recent addition (circa 2012) and may not be supported by all browsers yet.

Browser Support

The following browsers support X-Frame-Options headers.

Browser DENY/SAMEORIGIN Support Introduced ALLOW-FROM Support Introduced
Chrome 4.1.249.1042
Firefox (Gecko) 3.6.9 (1.9.2.9) 18.0
Internet Explorer 8.0
Opera 10.50
Safari 4.0Not supported/Bug reported

References:

Implementation

To implement this protection, you need to add the header to any page that you want to protect from being clickjacked. One way to do this is to add the header manually to every page. A possibly simpler way is to implement a filter that automatically adds the header to every page.

OWASP has an article and some code that provides all the details for implementing this in the Java EE environment.

The SDL blog has posted an article covering how to implement this in a .NET environment.

Limitations

  • Per-page policy specification

The policy needs to be specified for every page, which can complicate deployment. Providing the ability to enforce it for the entire site, at login time for instance, could simplify adoption.

  • Problems with multi-domain sites

The current implementation does not allow the webmaster to provide a whitelist of domains that are allowed to frame the page. While whitelisting can be dangerous, in some cases a webmaster might have no choice but to use more than one hostname.

  • Proxies

Web proxies are notorious for adding and stripping headers. If a web proxy strips the X-Frame-Options header then the site loses its framing protection.

Clickjacking defense for legacy browsers

The following methodology will prevent a webpage from being framed even in legacy browsers.

In the document HEAD element, add the following:

First apply an ID to the style element itself:

<style id="antiClickjack">body{display:none !important;}</style>

And then delete that style by its ID immediately after in the script:

<script type="text/javascript">
   if (self === top) {
       var antiClickjack = document.getElementById("antiClickjack");
       antiClickjack.parentNode.removeChild(antiClickjack);
   } else {
       top.location = self.location;
   }
</script>

This way, everything can be in the document HEAD and you only need one method/taglib in your API.

Reference: https://www.codemagi.com/blog/post/194

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets