Cross-Frame Scripting Attacks
Cross-frame scripting (XFS) is an attack technique that uses malicious JavaScript to access user data from a legitimate third-party page loaded into an HTML iframe. Combined with social engineering, this can allow an attacker to intercept keyboard events. Let’s see why XFS attacks are possible and how they differ from XSS.
Your Information will be kept private.
Your Information will be kept private.
How Cross-Frame Scripting Works
A cross-frame scripting attack starts by embedding a valid webpage into an iframe on a malicious page and tricking the user into visiting a site that the attacker controls, usually as part of a phishing attack. JavaScript is set up on the attacker’s server to listen for user-initiated events, usually keypresses, and the attacker can expand the iframe to cover the entire page for maximum realism.
In combination with a suitable browser bug, this may allow the attacker to obtain login credentials and other sensitive information from the unsuspecting user who is interacting with the framed legitimate site as usual. From this point of view, XFS can be considered a variety of clickjacking.
The Difference Between Cross-Frame Scripting and Cross-Site Scripting
Before we get into the technical details, let’s clear up the naming confusion. Despite the similar name, cross-frame scripting has nothing to do with cross-site scripting (XSS). There is a lot of unclear or misleading information online, even on the OWASP site, so to be clear:
- Cross-site scripting (XSS) means injecting malicious JavaScript to be executed by the user’s browser on a vulnerable website (which doesn’t have to be controlled by the attacker).
- Cross-frame scripting (XFS) means snooping on the user after tricking them to visit a malicious site that contains an iframe with a legitimate page.
That said, if the embedded page is vulnerable to an XSS attack, the two can be combined – more on that later.
When XFS Is Possible
Under normal circumstances, cross-frame scripting should not be possible because of same-origin policy – scripts shouldn’t have access to pages loaded from different servers, including access to their events. This means that even if an attacker managed to trick the user into visiting a framed site, the malicious JavaScript on the surrounding page couldn’t eavesdrop on the user’s actions within the embedded frame.
However, specific browser bugs might make it possible for a parent frame to access a child frame loaded from a different origin. If a vulnerable browser version is used to open a specially prepared malicious website (typically after clicking a phishing link), the attacker may snoop on the user’s actions. Note that a successful XFS attack requires all of the following to be true:
- The user receives and opens a malicious URL.
- The user’s browser has a buggy implementation of same-origin policy.
- The legitimate website that lures the user allows itself to be embedded in an iframe.
In this day and age, it is highly unlikely that all three conditions will be met. While users are still quite happy to click phishing links, finding someone who uses a browser with a suitable bug (such as some versions of Internet Explorer) would be a tall order. It is also common practice nowadays to prevent sites from being loaded into frames. All things considered, XFS can be regarded as a relatively minor web application security threat.
What Data Can Be Leaked
If successful, an XFS attack may extract key events and other browser events that provide information about the browser user’s activity on the framed page. Login pages are obvious targets for extracting credentials, but other pages can also be targeted to steal personal details and other confidential information. By manipulating the visible frame, attackers might also use XFS to perform clickjacking – or worse.
Can You Combine XFS and XSS?
Sure! After all, if a web browser bug allows a malicious page to access the JavaScript context of an embedded iframe regardless of its origin, cross-frame scripting doesn’t have to stop at event listeners. If the framed page contains a cross-site scripting vulnerability, additional JavaScript code can be injected into the legitimate page, paving the way for far more serious attacks than just snooping.
The attacker can inject malicious JavaScript into the iframe in many ways, depending on the XSS vulnerability being exploited. This could be as simple as entering code in the frame source URL. A typical attack might use an off-screen iframe to visit a legitimate page and then inject script to extract the current session cookie for a subsequent session hijack. While not much different from a meta redirect injection, the iframe version has the advantage that the user only ever sees the URL of the legitimate page in the address bar, making the attack harder to spot.
Preventing Cross-Frame Scripting
Even though cross-frame scripting vulnerabilities are not a major threat (unless you can find a reliable way to exploit an old IE bug or new bugs come along), controlling framing permissions in general is a basic web hardening practice to prevent clickjacking and similar attacks. Framebusting code was the legacy way to prevent your page from being framed, but many such countermeasures could be bypassed by a determined attacker. HTTP security headers are a much better way, with the X-Frame-Options header and the Content Security Policy frame-ancestors directive available to control framing behavior.
Checking your sites with Invicti is always a good idea, as it provides best-practice recommendations if it finds missing or misconfigured HTTP headers, including framing controls. And, as always, you should use a modern browser and update it regularly to minimize the risk of critical bugs. That way, you can at least be sure that something as fundamental as same-origin policy is always enforced as expected.
