?

?

Brief

Currently there is a vulnerability of some application which is the application can be opened? inside a frame, and the application does not detect whether the application has been loaded in frames, which could lead to an attack by which users are persuaded to perform site actions without their knowledge. This is called clickJacking or UI Redress attacks.

Solutions

Even through there are no particularly reliable and non-intrusive ways for applications to prevent attacks, Relatively there are two major approach to fix this issue,? one is use frame-busting scripts which is a client side solution, another is setting the x-frame-options in the http header which is a server side solution.

• Frame-busting scripts?

???????? This approach is to include JavaScript to detect having the page rendered within a cross-domain <IFRAME> , and try to break out of it, e.g.

                      try {
            if (top.location.hostname != self.location.hostname) throw 1;
         } catch (e) {
            top.location.href = self.location.href;
         }
                    

It should be noted that there is no strict guarantee that the update of top.location would always work,particularly if dummy setters are defined, or if there are collaborating, attacker-controlled <IFRAME> containers performing conflicting location updates through various mechanisms.A more drastic solution would be to also overwrite or hide the current document pending page transition,or to perform onclick checks on all UI actions, and deny them from within frames.
All of these mechanisms also fail if the user has JavaScript disabled globally, or for the attacked site.

Further more the busting scripts can be defeated also, one of the approach outlined below:

http://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed/

???? Pros:

• Almost all the browsers supproting this approach.

???? Cons:

• if the JS was disabled this approach will not work.

• This approach can also be defeated

???

• X-FRAME-OPTION

  Back in January of 2009, IE8’s support for a new header-specified directive: X-Frame-Options, that can be used to mitigate ClickJacking attacks. As a declarative security measure, X-Frame-Options has minimal compatibility impact, but requires adoption by clients and servers in order to provide its security benefit.
  Web developers can send a HTTP header named X-FRAME-OPTIONS on HTML responses to restrict how the page may be framed. By setting this value to DENY which will prevent the page from rendering if it will be contained within frame.
  Different browser will have different behaviour, some browsers (e.g. IE, Opera) will show a message that allows the user to safely open the target page in a new window. Other implementations (e.g. Chrome, Safari) will simply render an empty frame.
  Pros:

• This approach have no dependent on whether the JS was disabled or not.

• Currently there is no bypass solution for this, if the browser support x-frame-options.

???????? Cons:

• This approach will not take effect on some old version of browsers who is not supporting x-frame-options.

Browsers Supporting X-Frame-Options

• IE8+
• Opera 10.50+
• Safari 4+
• Chrome 4.1.249.1042+
• Firefox 3.6.9 (or earlier with NoScript)

Testing result with x-frame-options set to DENY

Testing result with frame-busting scripts