A UI redressing attack, also known as clickjacking or tap jacking, redresses or “redecorates” a target application, confusing the user who is interacting with the application. UI redressing attacks can be used to trigger any user interaction within the target application, such as clicking a button, dragging-and-dropping items, etc. A UI redressing attack uses various innocent features, combining them to trick the user into clicking a sensitive element. UI redressing attacks can be annoying, but also malicious. Examples of the former are Tweetbombs, which post-Twitter status updates to the victim’s account, and LikeJacking, which triggers unintended likes on Facebook pages. Examples of the latter are attacks that trick the user into enabling Webcam access for the Flash Player, and attacks on wireless routers, stealing the secret WPA keys.
The goal of a UI redressing attack is to forge a request from the victim’s browser to the target application, by making the user unintentionally interact with an element on a page of the target application. An attacker achieves this using misdirection, by redressing the UI of the page to hide the real element that will be clicked by the user. Many forms of UI redressing are possible, from transparent overlays to very precise positioning of elements, or even fake cursors stealing the user’s attention.
A UI redressing attack requires a coordinating application, which is under the control of the attacker and actually attracts legitimate interaction from the user. However, the coordinating application masquerades the target application, causing the user’s interaction to be directed towards the target application. The user actually thinks he clicks on the Play! button, but in reality, the click goes towards the invisibly framed page. Since both buttons are precisely positioned on top of each other, the attacker ensures that the user actually clicks in the right location. Note that the attacker requires the capabilities of a Web attacker, but does not control the target application and that the interactions of the user with the target application are indistinguishable from legitimate interactions. Mitigation techniques for CSRF attacks are ineffective against UI redressing attacks since the requests are not cross-origin, but actually originate from within the application.
While UI redressing attacks were traditionally known as clickjacking attacks, numerous variations have emerged as the technology evolved. Double clickjacking tricks the user into double-clicking, and quickly raises a previously opened pop-under window after the first click, misdirecting the user’s click to the target application, which is opened in the pop-under window. Another variation uses history navigation to preload a page of the target application in the context’s history and subsequently navigates to the attacker’s page. When the user is tricked into double-clicking somewhere, the attacker page quickly navigates the context to the previous page in the history, causing the user to click on a specific location in the preloaded target page. Instead of abusing clicking, an attack can also use the features of the drag-and-drop API to persuade the user to drag some text into the target application, thereby injecting data into form fields. Another variation is a cursor jacking attack, where a fake cursor is drawn on the screen, while the original cursor is hidden or out of the user’s focus on the screen.
Alternatively, stroke jacking abuses keyboard focus features to trick the user into typing in an input field of the target application. Finally, tap jacking brings UI redressing attacks to mobile devices, tricking the user into tapping on hidden elements. In essence, a UI redressing attack results in an unintentional request by misdirecting the interaction of a user. Well-conducted UI redressing attacks are impossible to observe, exonerating the users from all blame. UI redressing attacks can even be used to bypass an application’s mitigation techniques, such as an explicit confirmation request before performing sensitive actions.
UI redressing attacks commonly use frames to embed the target application. Traditional mitigation techniques, therefore, use frame busting code. Framebustingcode is targeted at detecting the unpermitted framing of an application, and subsequently breaking out of the frame by moving the application to a top-level frame. Simple frame busting code is often easily evaded, but carefully constructing robust frame busting code can withstand evasion, or fail in safe ways. The downside of frame busting is strict on or off mode, either allowing all kinds of framing or no framing at all, not even by trusted applications. In the modern Web, with mashups and composing applications, this might be problematic.
A second popular mitigation technique is the regulation of framing through the X-Frame-Options header. By adding this header to the response, an application can indicate that framing is denied, allowed within its origin, or allowed by an explicitly listed origin. Recently, the functionality offered by the X-Frame-Options header has been integrated into the Content Security Policy with the frame-ancestors directive. The frame-ancestors directive offers better support for nested browsing contexts, which are still vulnerable with the X-Frame-Options header, and supports multiple host source values, instead of the one supported by the X-Frame-Options header. Research on UI redressing attacks has also focused on a browser-supported solution that addresses the root cause, i.e., user misdirection. InContext incorporates several measures that ensure that a user’s click is genuine, for example by comparing screenshots at the time of the click, or by highlighting the area of the cursor to prevent attacks involving a fake cursor. InContext also serves as an inspiration for the new standardization efforts by W3C to ensure UI integrity in Web applications, effectively preventing UI redressing attacks.
The specification proposes several new directives to include in the Content Security Policy, giving the developer control over several heuristics to determine the genuineness of the interaction. Similar to other directives in the Content Security Policy, the browser will enforce these heuristics, blocking and reporting any violations. Finally, clickjacking can be combated from the client-side as well. The popular security add-on NoScript includes the ClearClick module, which does a screenshot-based comparison of the area to be clicked with the actually clicked element, and which served as an inspiration for the InContext work. When a difference between both is detected, the user is warned and explicitly asked to confirm the action, before the request is sent.
By design, all Web applications are vulnerable to clickjacking attacks, but the attack receives little attention compared to higher-risk attacks. Users of major, well-known Web applications such as Twitter, Facebook, etc. have fallen victim to clickjacking attacks, often indicated by spam messages making their way through the application. Many Web applications deploy some form of frame-busting code, of which several variations are known to be vulnerable to evasion. Additionally, many applications have a different front-end for normal browsers and mobile browsers, often only implementing frame-busting in their normal version. Currently, the X-Frame-Options header is gaining adoption. Our July 2014 survey of the Alexa top 10,000 domains discovered 2,159 domains that include an X-Frame-Options header in their responses.