ProClick: A Framework for Testing Clickjacking Attacks in Web Applications Hossain Shahriar, Vamshee Krishna Devendran, and Hisham Haddad Department of Computer Science Kennesaw State University, Kennesaw, GA 30144, USA {hshahria,hhaddad}@kennesaw.edu, [email protected]

ABSTRACT Clickjacking attacks are an emerging threat on the web. An attacker application presents a User Interface (UI) element of a target application out of context, such as hiding sensitive UI element by making it transparent to the end user. The user is tricked to click on the hidden element out of context. These attacks can cause severe damages such as compromising webcams and posting unintended messages. A large number of websites are still vulnerable to clickjacking and have no minimal protection at the server side (e.g., frame busting, X-Frame-Options header). Further, client-side defense techniques have been ineffective to deal with sophisticated clickjacking attack types and suffer from performance issues. This paper presents a proxy-level framework, ProClick, to detect clickjacking attacks. ProClick examines the content of requests and response pages at the proxy level to detect clickjacking attacks. We evaluate the proposed approach with a set of legitimate and malicious websites. The results indicate that our approach has low false positive and false negative rates. The overhead imposed by the proposed approach is also very negligible.

Categories and Subject Descriptors C.2.0 [COMPUTER-COMMUNICATION General, Security and protection.

NETWORKS]

H.2.7 [DATABASE ADMINISTRATION] Security, Integrity, and Protection.

General Terms Security, Languages, Verification.

Keywords Clickjacking, UI Redressing, ProClick, Proxy, iframe, X-FrameOptions.

1. INTRODUCTION Clickjacking attacks allure users to click on objects transparently placed in malicious web pages. The resultant actions of the click operation may cause unwanted operations in the legitimate websites without the knowledge of users [12,13,20]. This type of attack is also known as UI Redressing [4]. To perform a clickjacking attack, an attacker first designs a malicious web page containing an iframe which may load a legitimate web page or a GUI element. The iframe opacity level is set very low to make it barely visible to the user. The malicious web page allures the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIN’13, November 26-28, 2013, Aksaray, Turkey. Copyright © 2013 ACM 978-1-4503-2498-4/00/10... $15.00.

victim to click on a visible GUI element that is overlapped by the invisible web page(s) loaded in the iframe. If a victim clicks on the visible GUI element supplied by the hacker, it results in an action on the invisible web page and may cause unwanted consequences. For example, an attacker web page can trick users into clicking on a Facebook “Like” button by transparently overlaying it on top of an innocent GUI element containing a message such as “Claim your free iPad”. Hence, when the user clicks on the message, the click is applied to the “Like” button. The consequence of the click might result in posting a message in a Facebook page indicating that the user likes the attacker controlled website. Recent reports suggest that victims can be tricked to click on a wide range of websites such as social network (Facebook, Twitter) [5,17], shopping (Amazon, a victim ends up buying a book), and online banking [5]. One reported clickjacking attack is enabling the webcam and microphone of one’s computer without the victim’s knowledge [1,3] (which has since been corrected by Adobe). Other common incidents include following unintended user’s profile and posting messages on Twitter [5], sharing malicious links and liking unknown users on Facebook [17], and making individual profiles public [17]. Clickjacking attacks can be leveraged to generate revenues for large scale botnet operators. In particular, third party advertisements can be hosted on malicious websites created by botnet operators. Then infected computers are being sent links or phishing emails to view these websites and allure victims to click on these advertisements. The clicks directed to the advertisements can generate an estimated $6 million in revenue per month [19]. Thus, clickjacking needs to be addressed to prevent much of these unwanted consequences. Several clickjacking defense techniques have been proposed [5,7,17,18]. However, they all have limitations. The widely deployed defense is the inclusion of frame busting code [13,18] to disallow the rendering of a legitimate web page in an iframe. Unfortunately, frame busting is incompatible with embeddable third-party widgets, such as Facebook “Like” buttons. Another common prevention technique is to send special HTTP header (e.g., X-Frame-Options currently supported by Mozilla Firefox [16]) by the websites to disallow rendering pages in iframes. However, proxies located between the client and server side may strip these special headers. Also, older versions of web browsers do not support specific HTTP headers intended to prevent clickjacking. A number of open source tools have emerged to combat clickjacking attacks. Noscript [11] is a browser add-on to prevent clickjacking. It disables all JavaScript code running on the web page and gives control to the user to allow or disallow the execution of JavaScript code. This may reduce some clickjacking attacks mounted on top of JavaScript code. However, it suffers from performance issue and significant delays for users to perform necessary functionalities. Web of Trust (WOT) [10] is

another open source tool that can be an add-on for the browsers. It passively prevents clickjacking attacks by discouraging users to visit malicious web pages that are potentially framing legitimate websites in iframes. The tool relies on user ratings of malicious websites. However, an attacker might artificially increase the rating of his websites. Other existing defense techniques include user confirmation, UI randomization, and opaque overlay policy [17]. These techniques suffer from poor user experience, usability, and incompatibility with existing websites. Furthermore, new attack techniques (e.g., nested iframe, clobbering of object, event handler overriding) can easily circumvent existing clickjacking defense techniques [2]. Thus, there is a necessity to rethink the mitigation of clickjacking attacks and address some of the limitations of existing techniques. In this paper, we propose a framework, ProClick, for detecting clickjacking attack symptoms by analyzing web pages before being rendered to the browser. The framework is a client-side proxy which can intercept the incoming requests and response pages. We analyze the parameter values of request pages and HTML JavaScript code of response pages and perform systematic checking to decide if attack symptoms are present or not. Our approach can remove malicious content related to clickjacking attacks. Moreover, the framework can be extended to detect new clickjacking attacks. We implement a prototype of the proposed framework. The approach is tested against a set of legitimate and malicious websites. The evaluation results indicate that ProClick detects well known clickjacking attacks and shows low false positive rate. It also incurs negligible performance overhead and does not break up the source code of legacy web applications. Further, it does not depend on specific HTTP header or the enabling/disabling of JavaScript at the browser. This paper is organized as follows: Section 2 discusses an example of clickjacking attack. Section 3 highlights related work followed by examples of advanced attack techniques. Section 4 presents the proposed framework ProClick. Section 5 describes the evaluation results. Finally, Section 6 concludes the paper.

2. CLICKJACKING ATTACK EXAMPLE Here, we discuss an example of clickjacking attack that is performed by modifying a Facebook “Like” GUI element and hiding it in an iframe of a web page controlled by an attacker. The hiding of the GUI element is being done by making the iframe invisible based on Cascading Style Sheet (CSS) styling features. Figure 1(a) shows the HTML code while Figure 1(b) shows the display result. In Figure 1(a), a div tag named icontainer has a lower CSS zindex with an opacity level of zero. The div includes iframe fbframe that loads a clickable object “Like” from Facebook for an individual’s profile (xyz). The URL represents a clickable “Like” action element which can be embedded in any web page and if the element is clicked then the profile of xyz is being liked by the person who clicked it. Since the visibility of the div is zero, the loaded iframe will not be visible to the victim. To lure the victim to click on the element, the attacker places a lucrative message (CLICK HERE TO WIN AN IPAD) in the iframe (Figure 1(b)). Thus, making the victim think that clicking on the message will take him/her to another web page. However, clicking the link will initiate a “Like” action on Facebook for profile xyz without the victim’s knowledge. In Figure 1(a), note that the width and height of the div element (10, 12), iframe (50, 23), and the Facebook URL (450, 80) do not match with each other.

CLICK HERE TO WIN AN IPAD

Figure 1(a). Code for clickjacking attack using an iframe. If a website designer intends to place a “Like” object in his website in a legitimate way, then the width and height of the URL and the displayed container should match. This is an indication of malicious code.

Figure 1(b). Display of malicious page hiding iframe.

3. RELATED WORK AND ADVANCED CLICKJACKING ATTACK Although the same-origin policy is supposed to protect distrusting websites from interfering with one another, it fails to stop clickjacking attacks. As a result, several anti-clickjacking defenses have been proposed. We divide defense techniques into two categories: server-side and client-side. They are discussed in Sections 3.1 and 3.2, respectively. Section 3.3 discusses some variants of advance clickjacking attacks circumventing frame busting, one of the most popular defense techniques.

3.1 Server-side defense 3.1.1 Frame busting Website owners can protect their users against iframe-based clickjacking by including JavaScript code snippets in pages that need protection against clickjacking [18]. The code snippet in Figure 2 checks if a loaded web page is at the top window or not. If the current page is not in the top window, then it is loaded on the top window, thereby stopping the page loading in the iframe. A number of recent studies have found that most websites do not deploy frame busting code [2,18]. Thus, our work (applicable at the proxy level) can be a complementary approach for those websites without including any frame busting code. if (top.location != self.locaton) { parent.location = self.location; }

Figure 2. Code snippet for frame busting.

3.1.2 HTTP Header From the server side, the X-Frame-Options HTTP response header [16] can be used to indicate whether a page can be rendered in an iframe or not. The header can have three possible values: deny (prevents any domain from framing the content of a URL), same-origin (only allows framing of pages from the current website), and allow-from (a set of whitelisted domains that can frame a given URL). However, this technique requires sending HTTP header from each of the pages that need protection against clickjacking attacks. Another difficulty is the lack of support at

the browser side to understand the header and act appropriately (e.g., older versions of IE and Firefox will ignore the header).

3.1.3 HEAD Element A workaround is to apply a special HTML HEAD element containing a special style id with no display for a framed page. The page is displayed only if it is located as the top window [8]. We show sample code snippet in Figure 3. Here, we define a style object named clk1 which has no display information. The JavaScript code is a modification of the traditional frame busting code where the framed page is loaded on the top window (else part of the code). If the web page is loaded without any frame, then the defined style object is removed from the page and the original display is restored (i.e., if part of the code). However, this prevention technique can be easily thwarted based on reflective XSS filtering, clobbering of object, restricting JavaScript zone, event handler overriding, and multiple iframe usage. We discuss these attack techniques in Section 3.3. body{display:none;} if (self == top) { var antiClickjack = document.getElementById("clk1"); antiClickjack.parentNode.removeChild(antiClickjack); } else { top.location = self.location; }

Figure 3. Clickjacking defense using HEAD element.

3.2 Client-side defense Client side defense is divided into four types: confirmation/UI randomization, blocking of mouse click, detection of overlapping clickable elements, and disabling of JavaScript.

3.2.1 Confirmation/UI randomization A solution for preventing clickjacking at the client-side is to generate a confirmation dialog for end users to understand a possible out-of-context click [17]. Facebook currently deploys this approach for the Like button, asking for confirmation whenever requests come from blacklisted domains. Unfortunately, this approach degrades user experience, especially on single-click buttons. Another technique is to protect a target element by randomizing the UI (GUI element) layout of a legitimate web page. As a result, an attacker would fail to correctly locate the position of the target element.

3.2.2 Blocking of mouse click Instead of completely disallowing framing, an alternative is to allow rendering transparent frames, but block mouse clicks if the browser detects that the clicked cross-origin frame is not fully visible. Adobe has added such protection to Flash Player’s webcam access dialog in response to webcam clickjacking attacks. However, this defense only protects that dialog and is not available for other web content [17].

3.2.3 Detection of overlapping clickable element Balduzzi et al. [5] developed the ClickIDS Firefox extension. It compares the bitmap of the clicked object on a given web page to the bitmap of that object rendered in isolation (i.e, without transparency inherited from a malicious parent element). It alerts users when the clicked element overlaps with other clickable elements. Unfortunately, ClickIDS cannot detect attacks based on partial overlays or cropping, and it shows false positive warning.

3.2.4 Disabling of JavaScript ClearClick [7] offers a reasonable degree of protection against clickjacking attacks by disabling all JavaScript elements on rendered web pages. ClearClick prevents users from clicking invisible or redressed elements and applets. However, disabling JavaScript code execution may not be suitable for website owners and results in degrading performance for the website users. GuardedID [21] has added a Clickjacking warning feature. However, it cannot detect advanced clickjacking attacks.

3.3 Advanced clickjacking attack types We now discuss some advanced attacks (denoted as a1-a6) that are mounted on top of frame busting code.

3.3.1 Multiple iframe (a1)

If a legitimate web page is loaded inside a double frame (the inner iframe contains the target URL and the outer iframe points to the inner iframe page), then accessing the location of the parent window becomes a violation of the security policy enforced by all browsers. As a result, the frame busting code throws an error and clickjacking attacks can be successfully performed [8].

3.3.2 Event handler overriding (a2)

While loading a legitimate web page in an iframe, a user can manually cancel the navigation. An attacker can mount a clickjacking attack under this circumstance by registering an onBeforeUnload handler method at the top of his malicious web page. This handler is invoked when a page is about to be unloaded. The newly defined method can return a simple message to warn a victim of leaving the legitimate website. If a user chooses not to close that page, the action results in loading the target page in the iframe. This technique has been successfully applied to load Paypal website in an iframe [8]. Figure 4 shows sample code for the onBeforeUnload event handler overriding with a customized message “Do you want to leave http://www.xyz.com?”. Note that a legitimate website (http://www.xyz.com) is being loaded in an iframe after overriding the method. window.onbeforeunload = function(){ return "Do you want to leave http://www.xyz.com?"; }

Figure 4. Code snippet for event handler overriding.

3.3.3 No-Content Response (a3)

The event handler-based clickjacking attack requires user interaction. An alternative approach to avoid user interaction is to repeatedly submit navigation requests to a website and receiving HTTP response of 204 (no-content) from the legitimate website. Receiving a no-content flushes the request and cancels the original request forcing the original URL to load in an iframe [8].

3.3.4 Reflective XSS filtering (a4)

To date most browsers have built-in protection against reflective cross-site scripting (XSS) attacks based on known attack signatures. An attacker can arbitrarily supply a portion of JavaScript code to effectively eliminate the frame busting code present in the victim’s web page. As an example, an attacker may load the victim’s web page as follows: