RE: [webappsec] straw man anti-clickjacking proposal

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