- From: Fred Andrews <fredandw@live.com>
- Date: Wed, 5 Dec 2012 12:55:03 +0000
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <BLU002-W5583719ECF08A22540DDB8AA460@phx.gbl>
Thank you for the feedback David, Brad, and Giorgio.
If it were technically possible to present an input protected frame un-transformed and un-obscured then this still seems to me to be the best solution for the use case of a user wanting to protect content not designed to use the new UI safety event flags etc. For example input protection enabled via UserCSP. This need only be applied when the obstruction check fails, so should not affect the majority of content. Even using the new 'unsafe' flag, widgets will likely redirect to a new window to be unframed upon an obstruction test failure. Advertisements in an iframe can already expand when the mouse moves over them (with the cooperation of the parent), and pop up windows are generally permitted in response to an intentional events, so it is not immediately clear what extra pop-up capability might be exploitable to annoy the user but I appreciate this deserves more consideration. Perhaps there are some technical show stoppers to this option.
I agree that reacting to the 'unsafe' flag would be a good design for framed widgets. These widgets likely already open in an unframed window for safety when necessary (prompting the user), but can now use the 'unsafe' flag to detect some situations in which they can handle input safely while being framed. This has a good deployment path, and seems a clear win for this spec. If widget input fails the obstruction check then it can just fall back to prompting the user in an unframed window. The only issue would be widget authors that start to depend on the obstruction check alone and do not redirecting to an unframed page upon failure. The 'unsafe' event flag does not help if JS is disabled.
Giorgio, a fallback url may not help the use case of protecting content not written with the UI safety spec. in mind. It might help the JS-disabled case, and this might be something I am personally interested in for PUA options. If JS is enabled then the 'unsafe' event flag could be checked and might be used to better effect. It appears that ClearClick is still needed to protect general content and can not yet be replaced by UserCSP.
It is a complex solution space. I would need to explore the technical practicality of popping up an iframe to help more.
cheers
Fred
Date: Wed, 5 Dec 2012 10:01:27 +0100
From: g.maone@informaction.com
To: bhill@paypal-inc.com
CC: linshung.huang@sv.cmu.edu; fredandw@live.com; public-webappsec@w3.org
Subject: Re: UI Safety Obstruction check and transforms
Maybe an useful addition to address
this use case (parent site applying a CSS transformation to the
content, with intents which may or may not be malicious but in any
case make the obstruction check trigger) would be
input-protections options like
"fallback-url=" url
a URL (absolute or relative to the current document's) to be
opened if the obstruction check fails (by default in the "_blank"
context)
"fallback-context=" browsing-context-name
The context where the fallback URL should be loaded. If
fallback-context is specified by fallback-url is not, the current
document is loaded (from cache?) in the specified context.
This could be a declarative, simpler, scriptless way for authors
to provide a fallback page, shown in an independent "clean"
browsing context, to complete/confirm the transaction when using
UI safety in blocking mode and false positives are possible
because of the "creative" ways embedders may want to incorporate
sensitive widgets.
How does it sound?
-- G
On 05/12/2012 01:42, Hill, Brad wrote:
<hat=”editor”>
I
also think we might be more willing to consider an approach
to resolving this that does not involve prompting the user.
It is an explicit goal of this work to NOT prompt the user,
because users are not prepared to understand and respond to
such prompts, and therefore neither browsers nor application
authors have any interest in presenting such prompts.
This
is also likely only a problem with naïve use of “block”
mode. It seems that by using report-only or the “unsafe”
property, sites could respond to these and other kinds of
false positives in a way that doesn’t violate the contextual
integrity of the embedding resource as David points out
below.
Thoughts?
-Brad
From:
David Lin-Shung Huang
[mailto:linshung.huang@sv.cmu.edu]
Sent: Wednesday, November 28, 2012 12:03 PM
To: Fred Andrews
Cc: public-webappsec@w3.org
Subject: Re: UI Safety Obstruction check and
transforms
Hi Fred,
The idea of providing a force-topmost
(or force-opaque, etc) attribute or style is actually an
interesting approach and has been brought up a couple of
times by other researchers. However, as far as I know, it
is not simple in practice for the UA to guarantee that a
widget bypasses all transforms imposed by parents, while
rendering existing webpages properly. One thing to keep in
mind is that altering the appearance of webpages that are
non-attacks would be unacceptable to major websites
and browser vendors. We should also be concerned that such
a feature might be abused by widgets/ads to override
pixels on the parent page maliciously.
I think worth pointing out is that the
obstruction detection approach doesn't require modifying
the default appearance of existing webpages, and taking
screenshots is rather straightforward to implement while
agnostic to new HTML5/CSS/SVG features (proven feasible in
ClearClick and InContext).
Thanks,
David
On Wed, Nov 28, 2012 at 3:45 AM, Fred
Andrews <fredandw@live.com>
wrote:
Hi
David,
Thank you for the suggestion. I guess if a widget
received an event with this flag set it could
redirect to a confirmation page in which it was not
framed. However it is not clear if the event flag
could be used to bypass a transform imposed on a
widget by its parent to avoid the obstruction check
failure.
For example, consider a social widget that has
simply been scaled so that it fails an obstruction
check. A reasonable default action for the UA could
be to present the widget unscaled when hovering over
it. The UA needs to compute this unscaled view
anyway for comparison so it may not be a big extra
step. It may well be that the spec. already allows
a UA to do this, but it might be handy to have an
event sent to the widgets parent document to give it
the option to present the widget unscaled itself,
and perhaps this could even link into the CSS to
allow for 'unobstructed' styling when needed.
BTW: your papers are very good resources, thanks.
cheers
Fred
Date: Wed, 28 Nov 2012 00:22:33
-0800
From: linshung.huang@sv.cmu.edu
To: fredandw@live.com
CC: public-webappsec@w3.org
Subject: Re: UI Safety Obstruction check and
transforms
Hi Fred,
In Section 4 of the
draft, the proposed "unsafe" boolean flag in
the UIEvent object signals the webpage that
obstruction was detected by the UA (whether
it was caused by an attack or a benign
transform). This allows the webpage to react
with an extra confirmation dialog,
or implement other custom fallbacks.
Thanks,
David
On Wed, Nov 21, 2012 at
2:21 AM, Fred Andrews <fredandw@live.com>
wrote:
The issue
of transforms applied to an element
receiving an event has been discussed
before and the opinion offered was
that transformed elements are not
supported. Given that an element
needs to be non-transformed to pass
the obstruction check perhaps it would
be appropriate to support elements
being presented without transforms
when about to receive events. The use
case would be to support rich UI
designs that still offer UI safety.
For example, consider a UI that docks
social widgets at the side of a page
and scales them down and applies a
perspective transform for effect. If
input protection has been requested
then these widgets would need to be
presented unscaled and without the
transform to pass the obstruction
check.
Could a UA recognize the issue and
present the element in a little popup
when hovering over it, or could the UA
apply an extra confirmation step when
an obstruction is detected and present
the element unscaled and without the
transform for confirmation? If so
then perhaps an implementation note of
the possibilities would be
appropriate.
Might it be appropriate to signal an
event that the webpage could use to
implement such presentation itself,
with a default left to the UA? If so
then the spec. would presumably need
to define this event.
For the case of a docked widget, a two
step process would not be an
unreasonable UI design, and is there
enough support for webpage designers
to be able to implement such a design.
cheers
Fred
Received on Wednesday, 5 December 2012 12:56:28 UTC