Cross-Frame Scripting is a web attack technique that exploits specific browser bugs to eavesdrop on the user through JavaScript. This type of attack requires social engineering and completely depends on the browser selected by the user, therefore it is perceived as a minor web application security threat.
Conditions of a Cross-Frame Scripting Attack
The goal of an XFS attack is to steal user credentials for a certain website or web application. For this to happen, all the following conditions must be met:
- The website or web application must be vulnerable to XFS attacks and must control valuable user input (login data or other sensitive information).
- The attacker must place malicious JavaScript code on a web page that they control.
- The attacker must use social engineering (e.g. a phishing attack) to trick the victim to visit the web page that the attacker controls.
- The victim must use a vulnerable browser version (for example, IE6 on Windows XP)
It is very unlikely that all these conditions are met at the same time, especially since only old browser versions are vulnerable to such attacks. Therefore, an XFS attack is rather unlikely or must be specifically targetted, for example, at an organization that still uses old browsers and operating systems.
Anatomy of an XFS Attack
In a typical XFS attack, once the browser user visits the web page controlled by the attacker, the following happens:
- The legitimate page (usually a login page) is opened in an HTML IFRAME element.
- The IFRAME element is maximized to fill the entire page and the frame’s borders are removed so that the unsuspecting user thinks that they are visiting the legitimate site.
- When the victim attempts to log in to the legitimate website or web application, malicious JavaScript outside the IFRAME captures keyboard events (keystrokes) and sends them to the attacker.
In most browsers, this is not possible due to the Same-Origin Policy. This policy, which is standard in all modern browsers, prevents sharing of information via JavaScript between sites with different origins. Since the attacker-controlled page and the legitimate website or web application have different origins (different servers), it should not be possible for JavaScript on the attacker’s server to have access to key events from the IFRAME element that contains the third-party page.
Cross-Frame Scripting (XFS) vs. Cross-Site Scripting (XSS)
Despite the similarity in the name, Cross-Frame Scripting has nothing to do with Cross-Site Scripting, however, the two may be used together. XSS vulnerabilities and related XSS attacks happen because of vulnerable input processing on a vulnerable page while XFS attacks are mostly due to browsers not implementing Same-Origin Policy or implementing it with errors. Therefore, web application developers are not to blame for XFS vulnerabilities.
Cross-Frame Scripting is however very closely related to clickjacking. There is so much similarity that the methods used to protect your website or web application against clickjacking are, in most cases, also applicable for XFS protection.
How to Protect Your Web Application Against XFS
Since Cross-Frame Scripting vulnerabilities appear in web browsers, web application developers can only prevent frame embedding. There are three primary methods of protection. Since all of them are also used to protect against clickjacking, you can read all about them in our article How to Defend Against Clickjacking Attacks:
- Framebusting: The legitimate website owner only needs to modify the web page HTML code.
- The
Content-Security-Policy: frame-ancestorsheader: The legitimate website owner must modify web server configuration and have this header automatically included with every page. - The
X-Frame-Optionsheader: The legitimate website owner must modify web server configuration and have this header automatically included with every page.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
