1

We are implementing clickjacking protection using the X-Frame-Options header and possibly the JS/CSS setup described on this page:

https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

For reference, the JS/CSS solution looks like this:

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

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

Given the widespread support of the X-Frame-Options header in all modern browsers, I'm wondering if we should even keep the JS frame killer in place. Maybe just for good measure? If we do, we have the caveat that we use colorbox to generate iframe popups from within our own domain. This can be accommodated in the X-Frame-Options header by setting it to SAMEORIGIN, but I'm at a loss as to how I would modify the JS to allow frames from the same domain without it being easily circumvented.

As it is, the script compares self === top and removes the display:none; from the body style if they are the same. I can modify the condition to also check for the domain like so:

if (self === top || this.top.location.hostname === 'www.example.com')

But this uses the location object which can be changed from the framing page, effectively bypassing the script. Basically, I'm looking for something similar to this downvoted suggestion here:

https://stackoverflow.com/a/21900420/998048

So, 2 questions:

1.) Is it still considered best practice or even necessary to implement frame killing with JS?

2.) If so, is there a better, more secure way to keep the JS in place but still allow frames from our own domain?

Community
  • 1
  • 1
contendia
  • 161
  • 2
  • 9

1 Answers1

1

I still use the Javascript method because my setup doesn't allow me to use server side languages.

But this uses the location object which can be changed from the framing page

How so? If the location object is changed, your browser will redirect you to the new location object. If location.hostname was changed in the top window, it would redirect to your website. However I'd recommend using parent rather than top - otherwise all frames within other frames may redirect to themselves instead.

If the user has JS disabled, however, none of this will happen, so it may be a good idea to keep using X-Frame-Options. But for browsers that don't care about the X-Frame-Options header, keep the JS solution around I'd say.

tomysshadow
  • 870
  • 1
  • 8
  • 23
  • See this for more info on how `location` can be changed: (https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Clobbering_top.location) – contendia Jun 12 '14 at 19:13
  • The biggest problem I have with the JS solution is that we've been extra careful to design our site to fail gracefully if JS is disabled. However, if this script is in place and JS is disabled, a user won't be able to see the page at all. I know it works well for frame busting, but that seems drastic. – contendia Jun 12 '14 at 19:21