[Owasp-leaders] Clickjacking Cheat Sheet

Jim Manico jim.manico at owasp.org
Fri Nov 30 02:29:04 UTC 2012


Colin,

If you are using CSP then you definitely have a browser that supports 
X-Frame-Option headers (or you can use CSP's Clickjacking defense). In 
this case the JavaScript defense would be unnecessary.

For browsers that support XFO headers (the best Clickjacking defense if 
your browser supports it), please see 
https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header 
(XFO landed in Firefox 3.6.9, CSP landed in FireFox 4.0 - and XFO landed 
first in every other browser).

I read both articles you sited below. "Busting Frame Busting" is an 
excellent article. It shows how almost every common JavaScript 
framebusting technique was "busted". Please note, I talked to the 
Stanford team before supporting the current JS/CSS framebusting defense 
mechanism on the cheat sheet. The team was not able to defeat the 
defense methods of this nature. No one has, that I know of, and I 
looked. (Dear Stanford team, I still owe you Irish Whiskey, I'll honor 
that soon).

Also, for legacy browser clickjacking support, you NEED a method that 
has inline JavaScript in the <HEAD> for legacy browsers (the purposes of 
manual JS clickjacking defense) to prevent the page from being 
Clickjacked while the JS is being loaded.

This is complex stuff - happy to keep the conversation going if I missed 
anything.

Thanks for jumping in here Colin.

Respectfully,

Jim Manico
@Manicode
(808) 652-3805


> Jim
>
> This is a very welcome addition to the cheat sheet series. It may be
> worth referencing the following papers for further reading:
>
>     Clickjacking Attacks Unresolved
>     https://docs.google.com/document/pub?id=1hVcxPeCidZrM5acFH9ZoTYzg1D0VjkG3BDW_oUdn5qc
>
>     Busting Frame Busting: A Study of Clickjacking Vulnerabilities on
> Popular Sites
>     http://seclab.stanford.edu/websec/framebusting/framebust.pdf
>
> Regarding "Defending legacy browsers", the example code requires the
> use of inline JavaScript. This might not be compatible with a more
> robust Content Security Policy header. I have used a linked JS file in
> the header e.g.
>
>     <script src="/resources/scripts/site.js" type="text/javascript"></script>
>
> and in that file use the init() function to call something similar as
> already presented. I don't suggest the following is optimal, or
> currently matched to recent browsers. This dynamically adds the
> "hidden" style as a header, and then changes that. It relies on the
> timing of the page init event.
>
> = /resources/scripts/site.js ==============
>
> function start(){
>
> 	var fileref=document.createElement("link")
>    	fileref.setAttribute("rel", "stylesheet")
> 	fileref.setAttribute("type", "text/css")
> 	fileref.setAttribute("href", '/resources/styles/noframe.css')
> 	document.getElementsByTagName("head")[0].appendChild(fileref)
> 	if (self == top) {
> 		document.documentElement.style.visibility = 'visible';
> 	}
> 	else {
> 		top.location = self.location;
> 	}
> 	
> }
>
>
> function init() {
>      // quit if this function has already been called
>      if (arguments.callee.done) return;
>
>      // flag this function so we don't do the same thing twice
>      arguments.callee.done = true;
>
>      // kill the timer
>      if (_timer) clearInterval(_timer);
>
>      // do stuff
> 	start();
> };
>
> /* for Mozilla/Opera9 */
> if (document.addEventListener) {
>      document.addEventListener("DOMContentLoaded", init, false);
> }
>
> /* for Internet Explorer */
> /*@cc_on @*/
> /*@if (@_win32)
> 	document.write('<script id="__ie_onload" defer src=""><\/script>');
>      var script = document.getElementById('__ie_onload');
>      script.onreadystatechange = function() {
>          if (this.readyState == "complete") {
>              init(); // call the onload handler
>          }
>      };
> /*@end @*/
>
> /* for Safari */
> if (/WebKit/i.test(navigator.userAgent)) { // sniff
>      var _timer = setInterval(function() {
>          if (/loaded|complete/.test(document.readyState)) {
>              init(); // call the onload handler
>          }
>      }, 10);
> }
>
> /* for other browsers */
> window.onload = init;
>
> = /resources/styles/noframe.css ==============
>
> html {
> 	visibility:hidden;
> }
>
> =======================================
>
> And I think it may not be compatible with a strict CSP header
> implemented as "X-WebKit-CSP" in Chrome & Safari. I am sure this could
> be improved by someone more able than me, but in any case I think we
> should make example code CSP-friendly.
>
> Colin
>
>
> On 25 November 2012 23:48, Jim Manico <jim.manico at owasp.org> wrote:
>> The JS/CSS Clickjacking defense is made for legacy browsers that do not
>> support X-Frame-Option headers.
>>
>> Per https://www.codemagi.com/blog/post/194 it looks like IE6 and FF3x are
>> supported.
>>
>> Aloha,
>> Jim
>>
>>
>>> Looks good - has anyone tried the JavaScript to make sure it works?
>>>
>>> thanks,
>>> Andrew
>>>
>>> On Mon, Nov 26, 2012 at 9:10 AM, Jim Manico <jim.manico at owasp.org> wrote:
>>>> Leaders,
>>>>
>>>> I took the Clickjacking Defense Cheatsheet out of draft mode. Can you
>>>> take a
>>>> look?
>>>>
>>>> https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
>>>>
>>>> Your feedback and wiki edits are always appreciated.
>>>>
>>>> Aloha,
>>>> Jim Manico
>>>> @Manicode
>>>> OWASP Volunteer
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20121129/1bf53f31/attachment-0001.html>


More information about the OWASP-Leaders mailing list