W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

From: Michal Zalewski <lcamtuf@dione.cc>
Date: Tue, 30 Sep 2008 01:09:03 +0200 (CEST)
Message-ID: <Pine.LNX.4.64.0809300054230.10659@dione.cc>
On Tue, 30 Sep 2008, Robert O'Callahan wrote:

> If the chat gadget is configured to only talk to the site owner, how can it
> be abused? I suppose the site owner can discover the chat nick of a visitor
> who otherwise wouldn't want to disclose it. That's a risk that the chat
> system developers might very well be willing to accept.

Assume you are logged in with Facebook, Google, or any other "common" 
party that provides general chat / calendar services or anything of that 
kind; and let's say this party permits site operators embed a gadget that 
shows every visitor a schedule of events advertised on a page overlaid on 
top of visitor's schedule (with the option to add these to your calendar, 
or edit your calendar data - it does not have to be read-only); or gives 
you the opportunity to chat, review and annotate documents, or otherwise 
collaborate with site owners using similar facilities provided by gadget 
operator in their third-party domain, in your capacity as the user logged 
in with said services.

[If the visitor is not logged in, such a gadget would not display, or 
would offer a login link that pops up a new https:// window.]

This is not a very far-fetched scenario - I've seen designs of this type - 
and they are very much possible and safe to arrange without disclosing any 
user-specific information to the page that embeds said gadgets. The only 
security problem arises with UI redress flaws; so it would be nice to 
offer viable alternatives for such applications, too.

>> That's a terrible user experience, by most accounts, and goes against the
>> concept of a gadget; I believe it is often avoided at all costs except when
>> absolutely necessary (e.g., login, where the user needs the opportunity to
>> verify URL, SSL status, etc).
>
> Maybe we can make it a better user experience, for example, by allowing 
> the new window/tab to appear as a new pane at the top or bottom of the 
> existing tab. That would nicely handle your chat example, IMHO.

Possibly.

/mz
Received on Monday, 29 September 2008 16:09:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC