Cross-frame scripting (XFS)
What is cross-frame scripting?
In a cross-frame scripting (XFS) attack, the attacker intercepts sensitive information provided by the user by displaying a legitimate site in an inline frame and capturing keystrokes. XFS attacks resemble clickjacking attacks and are sometimes considered a type of clickjacking.
Note that a cross-frame scripting attack is only possible if the victim uses an outdated web browser. The attack also needs to be preceded by social engineering, so it is difficult to perform successfully. For these reasons, XFS is perceived as a minor cybersecurity threat.
How does cross-frame scripting work?
For a successful XFS attack, all the following conditions must be met:
- The target web page must accept valuable user input (for example, login credentials or other sensitive information).
- The victim must use a browser version with browser bugs that make it vulnerable to XFS (for example, Microsoft Internet Explorer 6).
- The victim has to visit the attacker-controlled web page following a social engineering ploy, such as a phishing attack using an open redirect.
Nowadays, it is very unlikely for all these conditions to be met at the same time, especially since only very old browser versions are vulnerable to such attacks. To have any chance of success, an XFS attack must be specifically targeted, for example, at an organization that still uses old browsers. But if all the conditions for a successful attack are met, the following chain of events occurs:
- The attacker places malicious JavaScript code on a web page they control.
- The victim visits the malicious web page, which then loads the legitimate page ( such as a login page) in an HTML iframe element. The frame element has its borders removed and is maximized to fill the entire page, so the victim thinks they are visiting the legitimate site.
- When the victim enters sensitive user data, the JavaScript code outside the iframe captures keyboard events (keystrokes) and sends them to the attacker.
Cross-frame scripting and the Same-Origin Policy
In most browsers, this attack is impossible due to the Same-Origin Policy (SOP). This mechanism, which is standard in all modern browsers, prevents sites with different origins from sharing information via JavaScript. Since the attacker-controlled page and the legitimate website or web application have different origins, it should not be possible for JavaScript originating from the attacker’s domain to have access to keyboard events from the iframe element that contains the third-party page.
Even older browsers such as Internet Explorer 6 already employed the Same-Origin Policy (which was originally introduced in Netscape Navigator 2 in 1995), but they did not use it for cross-frame communication. This is why XFS attacks are still possible if victims are using browsers with early SOP implementations such as IE6 and Firefox 2.
Cross-frame scripting vs. cross-site scripting
Despite the similarity in the name, cross-frame scripting has nothing to do with cross-site scripting (XSS). XSS attacks happen when a web application processes user input insecurely and allows an attacker to inject JavaScript, while XFS attacks involve displaying a malicious iframe to a user running an outdated browser.
How to detect cross-frame scripting?
Since a cross-frame scripting attack is aimed at a specific user and a particular version of that user’s browser, there is no way to detect any vulnerabilities in the web application itself, simply because there is no such thing as cross-frame scripting vulnerabilities in web applications. There are also no misconfigurations that make web servers vulnerable to XFS.
How to prevent cross-frame scripting?
You can theoretically protect your apps against XFS by sending protective HTTP headers from your web server, such as the X-Frame-Options header and the frame-ancestors directive of Content-Security-Policy (CSP). In practice, though, old browsers that are vulnerable to XFS don’t support these methods.The only viable way to protect old browsers against XFS is therefore to write client-side JavaScript that includes browser-specific framebusting functionality to completely prevent your site from being loaded into frames. While there is no point in including this protection for every website and application, it can be useful if, for example, you know that your web application is used by an organization that relies on an old and vulnerable browser.
Frequently asked questions
What is cross-frame scripting?
Cross-frame scripting (XFS) is a cyberattack technique where the malicious hacker targets a specific user with social engineering, tricks them into visiting a malicious site, includes a legitimate site in an invisible browser frame, and then captures sensitive information typed by the victim. This type of attack is most often used to steal login credentials.
Read an article about cross-frame scripting attacks on our blog.
How dangerous is cross-frame scripting?
Cross-frame scripting is considered a very minor issue simply because it requires the victim to use an old, vulnerable browser version, such as Internet Explorer 6 on Windows XP. The attack is not possible in modern browsers because they all fully enforce the Same-Origin Policy.
Learn about Same-Origin Policy and how it protects web browser users.
How to prevent XFS attacks?
The only way to prevent XFS attacks is to completely prevent your site from being loaded into frames – the same as with clickjacking attacks. Since XFS is specific to very old browsers, modern prevention methods such as X-Frame-Options and Content-Security-Policy are not supported. The only way is to use framebusting with legacy JavaScript code specific to the browser versions you want to protect.
Find out more about methods used to protect against clickjacking.
Related blog posts
Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler