Clickjacking: Attacks and DefensesLin-Shung Huang, Alexander Moshchuk, Helen J. Wang, Stuart Schechter, and Collin JacksonCarnegie Mellon UniversityMicrosoft Research

USENIX Security Symposium 2012

Outline

• Clickjacking Introduction• Existing Attacks• Existing Defenses• New Attack Variants• InContext Defense• Prototype Implementation• Experiments• Conclusion

Introduction

• Root Cause of clickjacking: an attack application presents a sensitive UI element of a target application out of context to a user• Hiding the sensitive UI by making it transparent

• Some possible risks caused by clickjacking• Web-surfing-anonymity can be compromised• User’s private data and emails can be stolen• Spy on a user through her webcam

Existing Attacks

• Three kinds of clickjacking attack:• Compromising target display integrity• Compromising pointer integrity• Compromising temporal integrity

Compromising Target Display Integrity• Hiding the target element• Using CSS opacity property and z-index property to hide

target element a make other element float under the target element

• Using CSS pointer-events: none property to cover other element over the target element

Claim your free iPadLike Click Event

Like

Claim your free iPadz-index: -1

opacity: 0.1 pointer-event: none

Click Event

Compromising Target Display Integrity (Cont.)• Partial Overlays• Overlay other elements onto an iframe using CSS z-index

property or Flash Window Mode wmode=direct porperty• Cropping• Wrapping target element in a new iframe and choose CSS

position offset propertites

PayPal Checkout

Paypal Information

Pay to attacker: 1000 USD Pay to charity: 10 USD

z-index: 1 Paypal iframe

PayPal Checkout

Paypal Information

Pay to attacker: 1000 USDCropping

Paypal iframe

Compromising Pointer Display Integrity• Hiding real cursor and create fake cursor• Using CSS cursor property and JavaScript to simulate a fake

cursor icon on the screen

Real Cursor Icon Fake Cursor Icon

cursor: none

Compromising Pointer Display Integrity (Cont.)• Keyboard focus “strokejacking” attack• Simulate an input field getting focus, but actually the keyboard

focus is on target element, forcing user to type some unwanted information into target element

Transfer

Bank TransferBank Account: ________ Amount: ___________ USD

Typing GameType what ever screen shows to you

Xfpog95403poigr06=2kfpx

[__________________________]

Attacker’s page Target Page (hidden iframe) within attacker’s page

95403062

Compromising Temporal Display Integrity• Cheat user within a short time• Manipulate UI elements after the user has decided to click, but

before the actual click occurs

Claim your free iPadLike Click Event

Consequences

• Tweetbomb: hide tweet button and trick user to click overlapping elements

• Facebook “Likejacking” attackes• Trick user to click OAuth approval page and steal user’s private

data• Upload private files via HTML5 File API

Existing Anti-clickjacking Defenses

• Same-origin-policy is not working here!

• FrameKiller: using JavaScript to detect whether target page is inside an iframe or not• Cons: not working on Facebook Like button

• User Confirmation: Ask user to re-verify the click event• Cons: degrades user experience

• UI Randomization: Randomize the position of the Pay button• Cons: attacker may ask victim to keep clicking until succeed

Existing Anti-clickjacking Defenses (Cont.)• Opaque Overlay Policy: forces all cross-origin frames to be

rendered opaquely• Cons: may break other benign websites

• Framebusting: similar to FrameKiller, but use HTTP header X-Frame-Options to ask browser not the render this page inside an iframe• Cons: same as FrameKiller, Facebook Like Button must within an iframe

Existing Anti-clickjacking Defenses (Cont.)• Visibility Detection on Click: block mouse clicks if the browser

detect that the clicked cross-origin frame is not fully visible• ClearClick: comparing the bitmap of target element rendered in

isolation, and the real target element on the page• Cons: may have a false positive problem

• ClickIDS: alerts when clicked element overlaps with clickable elements• Cons: cannot detect attacks based on partial overlays or cropping

• Cons: Non of those defense guarantee pointer integrity

Existing Anti-clickjacking Defenses (Cont.)• Give UI Delays: Give user enough time to comprehand what’s

happening. User cannot interact with the target element until the delay expires.• Cons: giving a tradeoff between user experience penalty and

protection from timing(temporal) attack

New Attack Variants

• We construct and evaluate three attack variants using known clickjacking techniques.

• Cursor spoofing attack to steal webcam access• Double-click attack to steal user private data• Whack-a-mole attack to compromise web surfing anonymity

Cursor Spoofing Attack

• Hide Flash webcam permission dialog inside Ads, and abuse pointer integrity

Double-click Attack

• Bait-and-switch attack: bait user to perform a double-click, and right after the first click, attacker switches user focus to Google OAuth pop-up window under the cursor right before the second click

First Click

Second Click

Whack-a-mole Attack

• Ask user to click as fast as possible,and suddenly switch Facebook Like buttonto user

• After clicked, immediately check the list oflike to get the profile of clicking victim

InContext Defense

• We propose a defense, InContext, to enforce context integrity of user actions on the sensitive UI elements

• When target display integrity and pointer integrity is satisfied then the system activate sensitive UI elements and delivers user input to them

• Use Operating System functions to provide such cross-application (or cross-web-site) protection

Guaranteeing Target Display Integrity• Not all webpages of a web site contain sensitive operations

and are susceptible to clickjacking• We let web sites indicate which UI elements or webpages are

sensitive

• Strawman 1: CSS checking• Check position offset, size, opacity, and z-index properties• Cons: not reliable enough since new CSS properties comes out

• Strawman 2: Static reference bitmap• Check rendered page with static bitmap data• Cons: different browsers render HTML differently

Guaranteeing Target Display Integrity (Cont.)• Use OS-level screenshot APIs to get bitmap of the sensitive

element rendering result• Use sensitive element rendered in isolation within browser for

comparison• If bitmaps don’t match, trigger oninvalidclick event when

user click the sensitive element

• Enforce host page that cannot apply CSS transforms property• Disallow any transparency inside the sensitive element itself

Guaranteeing Pointer Display Integrity• No cursor customization: disable cursor property when

sensitive element is present

• Screen freezing around sensitive element: to disable animation distracting the user’s attention

• Muting: loud noise may trigger user to quickly look for a way to turn it off

Guaranteeing Pointer Display Integrity (Cont.)• Lightbox around sensitive element: a randomly generated

mask to mask all rendered content around the sensitive UI element

• No programmatic cross-origin keyboard focus changes

Ensuring Temporal Integrity

• Time-Of-Check-To-Time-Of-Use (TOCTTOU) race condition

• UI delay: the click on the sensitive UI element will not be delivered unless the sensitive element has been fully visible and stationary long enough

• UI delay after pointer entry: impose the delay each time the pointer enters the sensitive element

Ensuring Temporal Integrity (Cont.)

• Pointer re-entry on a newly visible sensitive element: pointer must re-enter the sensitive element to activate the UI element

• Padding area around sensitive element: add a padding around sensitive element to let user distinguish whether the pointer is on the sensitive element

Prototype Implementation

• Using Internet Explorer 9’s public COM interfaces• IHTMLElementRender to get isolated rendering result• Check the aforementioned methods when the element is

visually changed

• Performance(Including time to take screenshot and bitmap comparison)

Experiments

• Post a Human Interactive Task (HIT) on Amazon’s Mechanical Turk

• 3521 participants, each HIT gives 25 cents• Exclude 370 previously participated users, 1087 users not

having Facebook logged in

• 10 treatment groups for cursor-spoofing attacks• 4 for double-click attacks• 13 for whack-a-mole attacks

Experiments on Cursor-spoofing Attacks

• 84% (43% of 51%(35/68)) users are attacked successfully• Timeout – wait for video ads end• Skip – click the skip link• Quit – quick the experiment• Attack Success – successfully get webcam permission

Experiments on Double-click Attack

• 47% users are attacked successfully• Timeout – didn’t click the OAuth “Allow” button after pop-up

window shows up within 2 seconds• Quit – quit the experiment• Attack Success – click the OAuth “Allow” button

Experiments on Whack-a-mole Attack

• Attack Success – user clicked the Like button• On 1st Mouseover – user clicked the Like button right after 1st

mouse over the Like button• Filter by Survey – user noticed the Like button and clicked it

Experiments on Whack-a-mole Attack (Cont.)

• 95%/92% user click the Like button right after mouse over it

• Combined defense – pointer re-entry, appearance delay of 500ms, display freezing, and padding(M)

Conclusion

• Devised new clickjacking attack variants

• Propose InContext, a web browser or OS mechanism to ensure user’s action on a sensitive UI element is in context