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?

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