- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Tue, 3 Jan 2012 12:50:00 -0800
- To: "Hill, Brad" <bhill@paypal-inc.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
> http://www.w3.org/Security/wiki/Anti-Clickjacking_Protected_Interactive_Elements Some comments: 1) "The protected context is displayed on its own topmost layout area that is not constrained by the original dimensions of the browsing context it is contained within. (e.g. a 200x200 protected context will display in full, even if triggered by clicking on a protected control in a 1x1 IFRAME) " Letting framed content escape their drawing area is a huge problem for the situation opposite to what you are focusing on: a trusted site (say, Facebook) embedding a framed untrusted gadget (e.g. a sketchy or perhaps XSSable web game). Heck, it is also troubling if mypaymentsite.com wants to embed the "like" button from Facebook, but doesn't trust Facebook to render credit card forms if Facebook gets compromised. Also, how do you plan to resolve conflicts when two sets of protected markup want to claim the same region of the screen? The content of IFRAMEs can be scaled down, rotated, etc, using CSS transforms on the embedding page; what happens to the protected markup then? 2) "With the interactive control, the application specifies a specific set of protected context markup. While the user is interacting with the control, the context markup MUST be displayed, and may not be obstructed or moved. A user-agent SHOULD dim or obscure display elements other than the protected context." One of the main criticism I received to my 2008 anti-clickjacking stawman was that it is apparently difficult for browsers to make this determination (spare of the screen-grab trick), because of the behavior of window managers, non-browser apps, etc. I'm not sure if this is an insurmountable problem (I doubt it), but that probably hinders the likelihood of vendor adoption. 3) "ClearClick in NoScript uses a screenshot comparison approach, looking at a diff between the rendered view seen by the OS and what an unobstructed rendering would give. This approach can be foiled by quickly moving or changing contexts just as a user interacts, so the screenshots have to be periodical or associated with some timeout period." I'm not sure how your proposal deals with such UI timing / repositioning attacks? For example, what prevents me from predicting the time of a mouse click, revealing the slider just moments before (see http://lcamtuf.coredump.cx/clickit/ ), and then while the mouse button is down, moving the window with the slider to the left to simulate dragging? Also consider rapidly switching between pages, which can be done pretty much seamlessly these days (see http://lcamtuf.coredump.cx/switch/ ), and may be enough to confuse the user into at least starting drag-and-drop. Once the action is initiated, do you expect that most users will understand how to abort the action? What if the slider is positioned close to the left edge of the screen (but still within the drawing area), so that dropping it back in the "off" location may be difficult on touchscreen devices? What if the slider is tiny because of CSS transforms? Also note that the sliding-motion approach is clearly not applicable to a wide number of uses and current UI paradigms (e.g., you probably can't do "slide to delete this mail", "slide to select 'delete' from the document edit menu", etc - at least on non-touchscreen devices, this would be cumbersome). I would be careful about calling this an "anti-clickjacking proposal" without some qualification :-) "A proposal for a non-clickjackable slider"? /mz
Received on Tuesday, 3 January 2012 20:50:51 UTC