Clickjacking Revisited A Perceptual View of UI Security Devdatta Akhawe, Warren He, Zhiwei Li, Reza Moazzezi, Dawn Song UC Berkeley Abstract they look like legitimate user actions to the application Clickjacking is a powerful attack against modern web backend. applications. While browser primitives like X-Frame- Current clickjacking defenses such as X-Frame- Options provide a rigorous defense for simple applica- Options sacrifice functionality for security. Using tions, mashups such as social media widgets require se- X-Frame-Options, an application can request the browser cure user interaction while embedded in an untrusted web- never to load a particular page in a frame. This is not a page. Motivated by these application scenarios, the W3C practical solution for third-party mashup applications UI safety specification proposes new browser primitives such as Facebook Like buttons. Instead, Facebook mitigates such attacks by requiring a second user click to provide a strong defense against clickjacking attacks 1 on embedded widgets. We investigate whether these pro- on a new window; again, sacrificing functionality for posed primitives provide requisite security against click- security. jacking. We observe that UI security attacks such as click- Motivated by the absence of defenses that preserve jacking are fundamentally attacks on human perception. functionality, the W3C recently started work on a UI Revisiting clickjacking from a perceptual perspective, we safety specification [25]. At its core, the specification re- develop five novel attacks that completely bypass the pro- lies on the InContext defense previously proposed by posed UI safety specification. Our attacks are powerful Huang et al. [14]. In the proposed specification, the with success rates ranging from 20% to 99%. However, browser permits cross-origin user interaction events (such they only scratch the surface of possible perceptual attacks as mouse clicks, touch events, or keyboard events) only on UI security. We discuss possible defenses against our if the event target (e.g., the Like button) was fully visible perceptual attacks and find that most defenses either have for a minimum amount of time. The aim of the proposal an unacceptable usability cost or do not provide a com- is to help applications defend against clickjacking attacks prehensive defense. Finally, we posit that a number of with minimal impact on functionality. attacks are possible with a more comprehensive study of We investigate whether the proposed UI safety speci- human perception. fication will protect applications against clickjacking at- tacks. Our key observation is that UI security attacks are 1 Introduction fundamentally attacks on limitations of human perception. User Interface (UI) security attacks, or UI redressing at- User interfaces strive for the integrity of user actions as tacks, including clickjacking [11, 14] and tapjacking [37], their invariant. In other words, any user interaction with present a difficult problem for modern web applications. sensitive UI elements should succeed only if the user per- Such attacks are a threat whenever mutually distrusting ceived, understood, and made a conscious decision to take principals (e.g., cross-origin iframes on the web) share the the particular action. This process falls under the domain screen canvas or interface. Using the shared canvas, the of human perception and action. attacker principal (i.e., malicious page) can trick the user We evaluate the proposed W3C specification against a into clicking on a third-party application frame (e.g., a simple model of human perception and find a number of Facebook Like button). For example, typical clickjacking limitations. Requiring that a UI element remain visible attacks rely on making the third-party frame (containing for a certain duration is a necessary but not sufficient con- the Like button) transparent so that the user does not re- dition for perception. For example, the W3C specification alize she is clicking on it. These attacks are particularly 1This defense is only turned on if the Facebook Site Integrity team difficult for the application to defend against, because suspects fraud, presumably due to usability concerns. 1 does not adequately consider an attacker’s ability to direct In a typical clickjacking attack, the attacker convinces user attention. Instead, it implicitly assumes that users a victim to click a seemingly innocent UI element, such as perceive any interface visible for a minimum length of a “skip ad” button. Unbeknownst to the user, the attacker time. In reality, a distracted user might not even notice overlays the button with a transparent iframe containing the presence of a sensitive UI element. a sensitive button (such as a Facebook Like button or a We develop five novel attacks that bypass the proposed PayPal “Pay” button). The web browser delivers any user UI safety specification. Other than our first attack, all our clicks to the overlaid, transparent target. proposed attacks also work on touch devices. We present Unknowingly interacting with a sensitive page causes our attacks and explain the underlying perceptual mech- unintended actions, such as undesired sharing of informa- anisms in play. We also make all our attacks available tion [1,9, 38, 42] or placing an order [14]. A recent study online [6]. of clickjacking vulnerabilities on top web sites showed The attacks we develop rely on multiple, distinct limi- that three of the Alexa Top 10 web sites and 70% of tations of human perception. Our intention is to demon- the top banking sites have no countermeasures against strate the breadth of attack possibilities when we take a clickjacking attacks [16, 44]. perceptual view of UI security. For example, our attacks Firefox introduced time delays to installation of addons vary from destabilizing pointer perception to attacking pe- and activation newer features (e.g., geolocation) to protect ripheral vision to even attacking limitations of the human against UI attacks. The browser disables the dialog but- motor system. tons until the dialog is visible for a fixed amount of time. To evaluate the practicality of these perceptual attacks, Other than in Firefox, time delays have not been adopted, we conduct a study with 568 participants on Amazon possibly due to the adverse impact on usability. Browsers Mechanical Turk. We find that our attacks have a success like Google Chrome instead switched to relying on two rate ranging from 20% to 99%. This is despite the fact that clicks to increase the difficulty of mounting a successful our attacks are prototypes and, as we discuss, a number clickjacking attack [7]. of improvements can make our attacks far more powerful. Initial web application defenses against clickjacking in- Our experience developing these attacks also suggests cluded framebusting [36], in which a site uses JavaScript that a number of attacks remain unexplored. to prevent other pages from including it as a frame. Rydst- Contributions. We make the following contributions: edt et al. identified a number of bugs in popular framebust- ing code [36]. Browser vendors added support for HTTP • We revisit UI security attacks as attacks on human header based mechanisms to prevent framing, including perception. X-Frame-Options [19] and its successors [25]. • We present a simple model of human perception Mechanisms such as X-Frame-Options and Framebust- and find a number of limitations in the UI safety ing protect only standalone applications and not mashups specification (Section 3). that rely on a shared canvas. For example, X-Frame- Options fails to enforce UI security for applications such • We systematically identify a number of novel UI as Facebook Like buttons that need to embed inside security attacks that bypass the defenses proposed in third party frames. Similarly, these defenses do not af- the W3C UI safety specification (Section 4. fect attacks that rely on cross-origin, overlapping win- dows [47, 48]. • We evaluate our attacks on 568 participants on Ama- For scenarios requiring a shared canvas, applications zon Mechanical Turk and find that our attacks have can use two defenses which work on existing browsers: success rates ranging from 20% to 99% (Section 5). confirmation dialogs and UI randomization. In the for- mer, the application asks the user for confirmation with 2 Background and Related Work a second dialog (a popup) before performing any sensi- Ruderman first warned of UI redressing attacks as early tive action [24,43]. This impacts usability and Facebook as 2002 [31–33].2 Zalewski [45] as well as Hansen and currently deploys this defense only if it already suspects Grossman [10,11] drew further attention to the problem fraud. Further, it is unclear whether the confirmation by applying the attack to the Web, in an attack they call dialogs are also vulnerable to UI security attacks. Al- Clickjacking. UI attacks are especially powerful since the ternatively, applications can randomize the location of server sees the attacker’s fraudulent messages as legiti- the sensitive buttons within their frame (as suggested by mate user actions. Hill [12]) to reduce the success rate of attacks and make large scale attacks easier to detect. We are not aware 2 Note to reviewers: We gave a presentation on some preliminary re- of any application relying on this defense. ClearClick, sults on these attacks at Blackhat USA 2013 and no paper was published. We believe it is acceptable to give presentations on work-in-progress, part of the NoScript Firefox extension, aims to protect its similar to giving talks at workshops. users from clickjacking attacks by comparing a screen- 2 shot of the target element rendered in isolation with a that violates display integrity includes an attacker that screenshot of the displayed page [24]. No browser de- covers the sensitive button with a “clickthroughable” im- ploys a ClearClick like defense by default, possibly due age [2]. Other variations include overlaying only part of to false-positives [14]. the sensitive target [15, 40, 46].