Cross Frame Scripting: Not Necessarily a Web Application Vulnerability

Cross Frame Scripting (XFS) is a vulnerability that affects web applications that use frames in their web pages. Frames allow web pages to present the web content framed in different sections of the browser window. A basic description of frames is included herein http://www.quirksmode.org/js/frameintro.html. When the browser renders the framed web page it also tries to load the web pages that each frame references to. This can be done either via HTML tags or by using javascripts either to load a web page within one frame or by calling a section of javascript code that resides in another frame. The security issue by calling javascript across the frames of a web page is that such scripts could be malicious if loaded through a user controlled variable. You can think of a XFS vulnerability as a sub-set of cross site scripting (XSS) vulnerability that is due of lack of input validation and output encoding when processing script from un-trusted source.

The general mitigation of XFS vulnerabilities for sites that use frames is to validate malicious input such as user variable (e.g. URL parameter in a GET request) that can be injected with javascript into a frame and executed on the user's browser within the context of the main page frame. An example is provided herein: http://www.owasp.org/index.php/Cross_Frame_Scripting

A web site that uses frames is potentially vulnerable to several vulnerabilities such as XSS, XFS and CSRF. In the case of XFS this vulnerability should be checked as part of an ethical hack of the web application. The main threat of XFS is that can be used for a phishing attack to steal user credentials. In this case, the malicious phishing site will frame in the legitmate web page section such as a login web page and execute a malicious script for a trojan such as key logger. The malicious frame can be injected via a XSS vulnerability and execute in the context of the legitimate frame.

To mitigate XFS vulnerabilities, modern browsers such as IE7 can help since are designed with security access controls that do not allow a javascript in one frame that belong to a certain domain (e.g. bank.com) to call a javascript of a frame that belong to a different, untrusted domain (e.g. malicousite.com).

Unfortunately, in case of early versions of IE browsers (IE 5.5 and 6.x) this XFS browser control can be bypassed leading to a well known vulnerability: Cross Frame Scripting Bypass: http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=77. If your web application use web frames and the user of your web application access your site via a vulnerable IE browser, the user is exposed to phising attacks that exploit this vulnerability. An example on how this XFS vulnerability is exposed by IE 6.x (will not work on IE7) and how can be used to execute a keylogger and display the user key strokes in the status bar is referenced herein: http://www.millersmiles.co.uk/identitytheft/cssb.html

The countermeasure for this browser vulnerability: use a non XFS control bypass vulnerable browser such as IE 7. Also, with Internet Explorer Vs 6 as well as Vs 7, inform the user of the browser setting "Navigate sub-frames across different domains", set to "Prompt" or "Disable": that protects your computer against the danger of cross-frame scripting attacks.

Other countermeasures are possible at the web application layer: introduce a frame busting javascript on the web pages. Such frame busting techniques consists on forcing the de-framing of the web pages to prevent the frames of your site to be jailed in someone else hacking frame. Basically a frame busting-out technique will cause the web page to be loaded by the browser to jump out of the frame that maliciously try to exploit your frame. The frame busting out technique consists on introducing the following javascript line on top of your web pages:

if(top != self) top.location = self.location;

When executing this javascript, the browser will check if the page is framed (top!=self) and set it to become the top frame (e.g. the whole page container) therefore causing the browser to render the full window without the frame.

The problem is that the effectiveness of this busting out javascript as XFS control should be considered more a deterrent then anything else. For example when using iframes the control can be rendered ineffective with IE by tagging iframes with "security=restricted "in the browser settings. This setting turns off JavaScript on the iframe and defeats the purpose of the anti-busting technique. An example is dealt with herein: http://crypto.stanford.edu/framebust/. Practically the effective risk mitigation from the user stand point is to use a non XFS vulnerable browser like IE 7.0 and newer versions of Firefox that have non vulnerable anti cross frame scripting controls. For users that use legacy browsers like IE5.5 and IE6.x versions the de-framing javascript (frame busting technique) in the web pages can help on mitigating the risk only as a deterrent control.

In summary you are much better off security wise not using frames and iframes in your web application. Possibly you should avoid using frames at least in all web pages that handle sensitive information (e.g. login web pages)