- From: Hill, Brad <bhill@paypal-inc.com>
- Date: Thu, 5 Jan 2012 12:55:25 -0700
- To: Michal Zalewski <lcamtuf@coredump.cx>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Thanks for the comments. Responses inline. > -----Original Message----- > From: Michal Zalewski [mailto:lcamtuf@coredump.cx] > Sent: Tuesday, January 03, 2012 12:50 PM > To: Hill, Brad > Cc: public-webappsec@w3.org > Subject: Re: [webappsec] straw man anti-clickjacking proposal > > > 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? [Hill, Brad] The escape from the frame would only be when a click/touch event was being actively routed to that content. This would prevent conflicts/overlaps, as the event can only be delivered to one sink. On release, rendering would revert. There are still some possibilities for abuse, but I think they are greatly diminished by the limited nature of the proposed control. You can't implement a credit card or password collection as a swipe, and any protected context you could force outside a frame would disappear again as soon as the user attempted to change focus. > > The content of IFRAMEs can be scaled down, rotated, etc, using CSS > transforms on the embedding page; what happens to the protected markup > then? [Hill, Brad] The protected markup would be rendered independent of transforms on the embedding page. The entire point is the protected context gets render itself topmost and as-if-isolated (cannot be moved, scrolled, scaled, etc. by outside influences), but only while accepting input. (onmousedown / touch and hold) > > 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. [Hill, Brad] Again, since the requirement would only apply when the control is receiving focus. I don't know of any window managers that allow changing or obscuring of a window when it is currently accepting input. The requirement to complete a swipe or the like also somewhat mitigates the context-switch trick. The user has to interact with the protected context. Even if you could get the "lightbox" display in a pop-under, you couldn't get the user to complete the swipe without seeing it. > > 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? > [Hill, Brad] Again, the implementation would have to prevent this, but only while the control had onmousedown, which I expect is simpler than trying to do so (or monitoring for such hijinks) continuously. > 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? [Hill, Brad] Things to think about here, definitely. I think that the slide/swipe gesture is pretty widely understood and accepted without a lot of user education. In the implementations I've seen, releasing the slider anywhere but at the full terminus of the track causes an abort. It's not perfect, but nothing is. > > 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 [Hill, Brad] Agreed. This is not a general purpose solution. Some of the limitations are deliberate, as mentioned above. It is an attempt to propose a (hopefully) simple solution to an ubiquitous and oft-attacked cross-domain framing use case for which (X-)Frame-Options cannot be effectively deployed.
Received on Thursday, 5 January 2012 19:56:01 UTC