In this blog post, you can learn more about frame injection attacks, such as Cross-Frame Scripting (XFS), how they work, and what you can do to prevent them.
What are frame injection attacks?
As a general category, frame injection attacks, sometimes also called framing attacks, denote the strategy of injecting frames into websites for various malicious purposes. These include using the frames to fool users into revealing their credentials, running a script on a user’s browser, redirecting users to malicious websites to perform a phishing attack, etc.
Frame injection attacks are listed under the injection category of the OWASP Top 10 2021 list though compared to other types of injection attacks, they pose a lesser threat.
However, given the right circumstances, a frame injection can also execute a clickjacking attack, cross-site scripting (XSS), cross-site request forgery (CSRF), frame hijacking, etc.
What is cross-frame scripting?
Cross-frame scripting (XFS), also known as an iframe injection, is one instance of a framing attack. It eavesdrops on users’ actions by loading a legitimate third-party page in an iframe that runs a malicious script. This is then used to leak keyboard events (i.e., keystrokes) and other browser events and capture user input such as login credentials. I.e., it is a form of phishing through frames.
Typically, since the same-origin policy (SOP) is part of all modern browsers, conducting an XFS should be impossible. The SOP prevents one origin from reading and accessing content from another origin. This means that a website hosting a frame that loads another website should not be able to read and record the frame’s contents.
However, old versions of some browsers with a buggy SOP implementation make it possible for events to be leaked across frames, which creates the possibility of executing a cross-frame scripting attack.
This type of attack is very closely related to the clickjacking attack since both use a similar approach though to a different effect.
How does cross-frame scripting work?
For an XFS to be possible, the following conditions must be met:
- The attacker must target a legitimate website that controls user input, such as a login page, and that website must allow being embedded in an iframe (i.e., it must be vulnerable in that way)
- The attacker must control a website on which they host the iframe that will load the legitimate website along with JavaScript code which they will use to capture user-initiated events.
- A user must have a browser with a faulty SOP implementation that allows for events to be leaked across framesets.
- The attacker must successfully lure the user to the website under their control via social engineering and trick them into performing actions that can be recorded, such as logging into the embedded website.
If these conditions are in place, a cross-frame scripting attack may succeed. For this purpose, an attacker will position a frame on a page they control (fakewebsite.com) that will display a legitimate website (realwebsite.com). They will expand the frame to fill the whole page and hide its borders so that it cannot be distinguished from the actual realwebsite.com.
The attacker will also set up a JavaScript code on fakewebsite.com to listen to user events and record these, which is possible due to the faulty SOP implementation. As a result, when a user attempts to log in at realwebsite.com, their actions will be recorded, and their credentials will be captured.
Other uses of XFS
Cross-frame scripting can potentially also launch cross-site scripting (XSS) attacks. Given a buggy SOP implementation, if the targeted website embedded in the frame is also vulnerable to a cross-site scripting attack, XFS can be used to that end. This would allow attackers to do more than just eavesdrop but inject malicious code, steal cookies, and then hijack sessions.
Technically speaking, there is no significant difference between launching a regular XSS or an XSS through XFS. Conducting cross-site scripting through a frame may be more stealthy, but its effects are the same. The element of greater secrecy is achieved by loading the legitimate website in a frame and then hiding the frame. When the user visits the attacker’s website, the frame will load the other website along, and the cross-site scripting attack will be performed entirely without the user’s knowledge.
How to prevent cross-frame scripting and frame injections
Cross-frame scripting vulnerabilities are due to faulty same-origin implementations and browser bugs. For this reason, developers are not to blame for instances of XFS. However, this does not mean that there is no cross-frame scripting fix that you can implement. Given how similar cross-frame scripting and clickjacking attacks are, some of the measures you can take are the same as when preventing clickjacking.
Here’s what you can do to stop or reduce instances of XFS and other frame injection attacks:
- Use the Content Security Policy (CSP) to whitelist valid iframe sources specifically. This can be achieved through the frame-src, child-src, or frame-ancestors directives that allow you to control framing behavior and sources.
- Use the X-Frame-Options header to specify whether a page can be rendered in a frame or not. Consider including this header automatically with every page.
In addition, attackers can inject frames via a URL containing JavaScript by exploiting cross-site scripting vulnerabilities. To prevent this, you should also:
- Block user input in URLs where possible
- Define a list of accepted URLs, if you need to use dynamic URLs
- Only accept URLs that come from whitelisted domains
FAQ
What is a frame injection?
Frame injection uses hidden frames designed to trick users into performing specific actions – such as revealing their credentials, clicking on a malicious link, or running a script without knowing. Cross-frame scripting and clickjacking are instances of frame injections.
How dangerous are frame injections and cross-frame scripting?
XFS is a way of phishing for users’ data via browser events (such as keystrokes). The conditions required to execute this attack are difficult to achieve, making it less dangerous. However, given the right circumstances, it can be combined with other attacks, such as XSS, CSRF, redress attacks, etc.
