In unserem Blog veröffentlichen wir in unregelmäßigen Abständen Artikel zu verschiedenen Themen der IT-Sicherheit, wie z.B. Open Penetrationstests und anderen öffentlichen Gutachten.

UI Redressing (UIR) describes a set of powerful attacks which can be used to circumvent browser security mechanisms like sandboxing and the Same-Origin Policy. In essence, an attacker wants to lure a victim into performing actions out of context by commonly making use of social engineering techniques in combination with invisible elements and hijacked trustworthy events. The set of attacks includes techniques like manipulating the mouse cursor, stealing touch gestures, and maliciously reuse keystrokes. Introduced in 2008, clickjacking was the first UIR attack which made it possible to automatically hijack the camera and microphone of the victim by stealing a few left-clicks within a Flash-based browser game. 

clearClick

Figure 1:  Illustration for a classic clickjacking attack. Instead of clicking on the visibile More button, the victim is clicking on an invisible Like button within a transparent Iframe which overlays the More button.

In a classic clickjacking attack derived from the Flash player attack and illustrated in Figure 1, the victim has opened the attacker’s website, which consists of at least two Frames. In an example with two Iframe elements , the first Iframe ("Funny Kittens") is loading a visible HTML document to lure the victim into clicking on the More button; this can be also integrated directly on attackers.org without using an Iframe element. The second Iframe loads the target website (e.g., Facebook), but this frame is rendered invisibly (e.g., with the help of the property opacity=0) on top of the visible frame. Because of invisible Iframe’s position above the Funny Kittens Iframe, the victim will actually click on Like instead on More.

From a defenders perspective, it therefore an important task to disallow another website to load your website within a frame. Due to this reason, this blog post tries to answer the following question by discussing different countermeasures like JavaScript-based Frame Buster and the HTTP header X-Frame-Options scientifically:

  • How can we prevent framing attacks?

1. JavaScript-based Frame Buster

To be able to control the layout of the victim's website, the attacker usually loads the target Web page into an Iframe. Standard countermeasures implemented in the attempts to shield a website from being framed are JavaScript-based frame busters. They usually consist of a conditional statement and a counter-action. The conditional statement verifies if the website implementing the frame buster is loaded in an Iframe. In such case, the counter-action will be executed. Thus, if attackers.org wants to load victim.org in an Iframe, attackers.org will be busted to victim.org.

In July 2010, Rydstedt et al. put forward a statistical inquiry into the usage of frame busters. The researchers came to the conclusion that frame busters are the most widely used technique against classic clickjacking. Nonetheless, frames can be attacked in many different ways via busting frame busting attacks. A recommendation against the classic clickjacking attack, as well as the frame busting attacks, was published by Detlefsen in October 2010. This new kind of frame buster is displayed in Listing 1. Detlefson et al. used Cascading Style Sheets to ensure that the whole body of the document will not be displayed to the user. After that, they used JavaScript to check if the page is being framed or not. If the latter is the case, the body of the document will be displayed to the user. Otherwise, the frame will be busted.

Therefore, since the execution of JavaScript code will be deactivated if there is a frame busting attack, the content of the Web page will not be displayed. This countermeasure is purely JavaScript-based, thus it is applicable to modern browsers. After manually analyzing the Alexa Top 500 websites in June 2018, we want to stress that this kind of JavaScript-based frame buster is one of the most attack-resistant countermeasures against the busting frame busting techniques. 


<style id="antiClickjack">
  body{display:none !important;}
</style>
<script type="text/javascript">
  if (self === top) {
    var antiClickjack = document.getElementById("antiClickjack");
    antiClickjack.parentNode.removeChild(antiClickjack);
  } else {
    top.location = self.location;
  }
</script>

Listing 1: An example for a frame buster proposal by Detlefsen. The target is to prevent a website against being framed and to be resistant against busting frame busting attacks.


2. X-Frame-Options

Using the HTTP header X-Frame-Options (XFO) provides another way of tackling framing attacks. Developed by Microsoft in 2008 and implemented since Internet Explorer 8 this header's use forces a supported browser to check if a website should be loaded in a frame or not. In contrast to the JavaScript-based countermeasure, the frame will not be busted. Instead, a warning message inside the frame will be displayed. In October 2013, Ross et al. published a document about XFO with RFC 7034. They go into detail regarding the header's syntax, the agumented Backus-Naur form, and inter alia design issues. Huang et al. underlined that XFO is "fundamentally incompatible with third-party widgets, such as Facebook Like buttons". Therefore, we need at least another technique to handle this problem. Potential solutions are, for example, discussed later in the section about NoScript. Nonetheless, Braun and Heiderich showed in the fall of 2013 that this HTTP header can also be used to defend the user against other attacks like the docmode-problem and invisible site-wide XSS.

Microsoft introduced three different values for the header in question. These are: DENY, SAMEORIGIN, and ALLOW-FROM origin. If one wants to forbid all Web pages from loading the protected Web page in a frame, then DENY should be used. To allow a Web page of the same domain to load the protected Web page, one should use SAMEORIGIN. The last value gives an option of specifying a URL allowed to frame the protected Web page. In this case, the URL has to be replaced with one specific origin (this value was not successfully implemented in all browsers due to an implementation error in Firefox).

At the time of introducing XFO, the main disadvantage of this HTTP header has been its limited support in web browsers. For this reason, most of the websites are still using the JavaScript-based countermeasure. Please note that XFO was marked as deprecated by Mozilla in 2013 – however, they removed this status and you should still use it. They recommend to use the Content Security Policy instead of XFO. This might be a bad idea due to the reason that developers will not use XFO and just the CSP – implicating that user of older browsers will not be protected.

Please note that XFO does not defend the user against all kinds of clickjacking. For example, cursorjacking relies on CSS code that is used on the attacked website. Zalewski showed in 2011 that browser games can be utilized to attack the victim with clickjacking attacks. He lets the victim click on several buttons and after a few clicks a button is changed right after the mouse cursor has moved over it. In this case, the victim is clicking on a sensitive element (e.g., Facebook's Like button) that is loaded in another window (e.g., pop-down window). The user does this because humans typically focus their attention on elements that are animated (e.g., moving buttons) and thus they are not concentrated on events like window changes. Zalewski's attack technique is similar to double clickjacking.


X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: allow-from https://example.org

Listing 2: Examples for different vairants of the XFO header. According to Shodan, XFO with the value SAMEORIGIN is the most popular implementation variant. Lawrence has also published a few best practices regarding the usage of XFO.


3. Content Security Policy

Content Security Policy (CSP), with its version 1.1 was originally developed by Mozilla and it is specified by the W3C Web Application Security working group. The primary goal of CSP is to mitigate content injection vulnerabilities, like Cross-Site Scripting, by determining at least one domain as a valid source for scripting code. To achieve this goal one can use a directive like frame-src or sandbox. In the case of frame-src it is, for instance, possible to let a supporting user agent check which frames can be embedded in a website. It is therefore possible to gain a fine granularity about the allowed content on a controllable website. Thus, CSP is capable of reducing the potential harmful effects of malicious code injection attacks. Note that CSP considers inter alia arbitrary styles, inline CSS, and Web fonts as possibly harmful and therefore provides matching rules.

CSP and UI Redressing. In the CSP Level 2 draft of September 2014, frame-ancestors can be used as a directive to allow or disallow embedding resources loaded, for example, via frame, iframe, embed, or equal elements. Full CSP supporting browsers do not need XFO any more to protect the user against some UI redressing attacks. However, especially the older browsers do not support the CSP (or just parts of it) and thus X-Frame-Options should be still used.

UI Security and the Visibility API. Furthermore, there are W3C Editor Drafts of the "User Interface Security Directives for Content Security Policy" specification. Though such directives are a good idea, Akhawe et al. pointed out that there are limitations in the UI safety specification by identifying bypasses (e.g., they used cursorjacking techniques). In essence, they let the victim focus on one area of the screen, while he is interacting with another area. There are five directives specified in the W3C Working Draft from November 2012 to achieve more UI security: frame-options, input-protection, input-protection-clip, input-protection-selectors, and report-uri.

First, frame-options has like the HTTP header XFO the directive values deny and 'self' ['top-only'] to disallow all Web pages or all other Web pages, except same origin Web pages, to be loaded in a frame. Furthermore, a posible directive value can also be 1*1 ['self'] or 1*1 'top-only'. Please note that there will be only checked the origin of the top-level browsing context if top-only is used. The value self ensures that all ancestors have the same origin. Second, the directive input-protection has the value ["display-time=" num-val] ["tolerance=" num-val]. In the first case, display-time can have a milliseconds value from 0–10,000. This ensures that the displayed page is continuously unchanged during user interactions like click or touch events. The tolerance defines the threshold at which the protection triggers the violation with a value from 0–99.

In addition to input-protection, the third directive input-protection-clip defines a rectangular area, instead of the whole document, with coordinates that should be analyzed by the input protection heuristic. DOM selectors, like #chapter1 to select the ID-typed attribute with the value chapter1, can be used with the fourth directive input-protection-selectors. Last but not least, the fifth directive report-uri allows the Web page administrator to specify a URI to which a policy violation can be submitted as it is the case of the W3C Content Security Policy 1.0.


Content-Security-Policy: frame-ancestors <source>;
Content-Security-Policy: frame-ancestors <source1> <source2> <sourceN>;
Content-Security-Policy: frame-ancestors 'none';

Listing 3: Different ways to implement a framing policy. In contrast to XFO, frame-ancestors allows to define multiple sources.


4. Browser Extensions

Firefox NoScript. Developed by Maone, NoScript is an extension for Mozilla-based Web browsers like Firefox. It allows JavaScript, Java, Flash and other plugins to be executed by a trusted website of the users choice. In addition, there is inter alia an XSS protection integrated concerning UI redressing; the extension provides a plugin called ClearClick since version 1.8.2. Due to Firefox Quantum, NoScript was rewritten as a WebExtension in 2017 and since then the support for ClearClick is not available anymore. However, there is a still maintained legacy version of NoScript.

clearClick

Figure 2: A screenshot of NoScript's ClearClick extension detecting an SVG masking attack.

ClearClick recognizes clicking and typing on hidden elements and reveals the element in clear by showing a "ClearClick Warning'" window as it is displayed in Figure 2. This detection is realized by analyzing the percentual pixel difference of the clicked window and the window without, for example, features like mashup overlays or frame borders. The threshold to trigger the protection can be configured through the about:config page in Firefox via noscript.clearClick.threshold. According to Maone, the thresholds "default value, based on the observation of several samples of false positives collected through the Report button on the ClearClick alert dialog, is 18%".

Furthermore, NoScript protects the user, for example, against the usage of Iframe elements (optional). It blocks such frames in untrusted and trusted Web pages, which try to load content from untrusted Web pages.

NoScript and Chrome. NoScript is nowadays also available for Google Chrome (very equal to the Firefox Quantum release). Moreover, it should be mentioned that Google Chrome has also a similar sounding plugin such as NoScript. This plugin is called NotScripts and it, for instance, does not provide advanced protection for clickjacking. Therefore, the clickjacking mask of Figure 2 does not appear by using this plugin; the figure shows a prevented SVG masking attack.

Scientific Countermeasures

InContext and IronFrame. In 2012, Huang et al. introduced InContext for enforcing target display integrity. Three years later, Kaminsky introduced IronFrame. The main idea is to show iframe elements always on the highest layer so that they cannot be, for example, (partially) overlayed with other elements.

However, InContext's functionalities make a deeper analysis. Based on a prototype developed for Internet Explorer 9, InContext's inter alia used COM interfaces to compare screenshots on the operating system level. Their tool analyzes the area containing the sensitive element (e.g., Facebook's Like button) in two cases: First, when it is rendered in isolation. Second, at the time of user interaction. If there is a difference between both bitmaps, the action will be cancelled and a new oninvalidclick event will be called. Based on this event, the application could deal with the cancellation. This approach is similar to NoScript's ClearClick, though there are two main differences: InContext uses operating system APIs and it is opt-in, which means that the website has to explicitly mark sensitive elements.

ClickSafe. In 2014, Shamsi et al. published a Firefox extension called Clicksafe; sadly, this extension is no more available. The authors determined that most of the clickjacking defenses try to work before the user has clicked on an element. Clicksafe works after the click by searching for code that could forward the victim to a malicious website, for example via an onclick event-handler. If the user is clicking on such an element, there will be displayed a pop-up window with a warning message and different ratings. The first rating is using MyWOT so that the user can see if the website is flagged as malicious by the Web of Trust community. The other two ratings are from the ClickSafe community and from a previous user rating – in the case that there is at least one. If the user decides that the action is malicious, he could cancel it. Otherwise, the code will be executed.

Remarks and general recommendations

Web applications have different goals and therefore one has to check each application individually to select the perfect fitting countermeasures. However, in general we recommend to implement XFO whenever it is possible; it also mitigates other framing attacks beside clickjacking and is therefore a very attractive tool. In addition, JavaScript-based Frame Buster can help to implement a countermeasure against framing attacks in legacy browsers.

Weichselbaum et al. have shown that there are many ways to bypass the CSP due to insecure configurations and therefore one has to implement the CSP very carefully. As an example, web developers could consider it before building a new application (e.g., with no inline scripts); the Mozilla Observatory tool might help you to avoid some mistakes. However, at least in case of CSP's directive frame-ancestors we have the possibility to whitelist multiple websites and not only one such as in case of XFO – this could be the crucial factor in your decision process.

As a client-side countermeasure, NoScript's ClearClick is a very good countermeasure. As a major downside, ClearClick is only available in older NoScript and thus Firefox versions.

In case that you are interested in this topic and if you would like to get more information, I have written a PHD thesis about UI redressing attacks and countermeasures. Feel free to write me a mail if you have any questions or comments regarding this blog post – I would be happy to answer them.