W3C home > Mailing lists > Public > public-appformats@w3.org > December 2007

Re: Widget Security

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 14 Dec 2007 14:06:22 -0500
Message-Id: <9E4C824D-940C-4F38-BDEC-B825BAB76638@nokia.com>
Cc: public-appformats@w3.org
To: ext Thomas Roessler <tlr@w3.org>

Thomas, All,

First, thanks Thomas for your e-mail!

On Dec 5, 2007, at 3:44 AM, ext Thomas Roessler wrote:

> I've had a look at some real-life Widgets during the last two or
> three days and, as a result of that, would have some input to the
> security considerations.  Or rather, I'd like to suggest a section
> (or a note) on good practices for Widget (and, in fact, Web
> application) development.

Yes, some good practices regarding security considerations for  
browser-based Web Applications and Widgets would be useful. And of  
course the Security Model section of the Widgets spec is still  
empty :-(.

If anyone is interested in contributing to such documentation, please  
let us all know. Note that if you don't work for a W3C Member, we may  
be able to accommodate you via the W3C's Invited Expert mechanism  
(see [1] and follow-up with me).

I have a few additional comments below.

Regards, Art Barstow

[1] <http://www.w3.org/Guide/Status.html>

> (Note that much of this also applies to Web applications that run in
> a browser and reach out to multiple origins to obtain data.  Based
> on what I've seen in the last couple days, I've come to believe that
> we're in for some interestingness in that area, too.)


> Actual widgets look pretty bad in terms of code quality.  The
> Twitter widget issues I described last are really just the tip of a
> rather large iceberg.  There are more vulnerable widgets, and more
> severe vulnerabilities.

Ouch; agree the vulnerabilities should be documented (perhaps we  
could start with a wiki).

> However, in this message, I don't want to focus on individual
> examples, but rather on what this group should do.
> Here are some of the things to discuss in terms of development good
> development practices; I'm sure this can be organized much better:

Yes, it would be good to document recommended practices.

Perhaps we can leverage some of the work you've done in the WSC- 
Threats note:


> In fact, there might be a way to mitigate the "cross-site scripting"
> side of things that could be attractive to spec and deploy: What if
> vendors were to put a bargain into code in which the use of
> innerHTML, Document.write, and friends, or the insertion of script
> tags which load a script from an external source would tie the
> Widget to the traditional browser sandbox model?

Interesting. What do others think about this?

> There are at least two ways to do this:
> - Restrict future JavaScript method invocations to the traditional
>   sandbox model once the risky coding style has occured (i.e.,
>   innerHTML, document.write, ...).  This is most likely to have the
>   least impact on existing widgets; however, from a programmer's
>   perspective, it is likely to lead to a certain amount of pain, and
>   to hard-to-debug bugs.

Agree this would be painful.

> - Throw a security exception if any of the risky techniques are used
>   in a Widget that has access rights beyond the traditional sandbox.
>   That would be feasible for some of the currently deployed engines,
>   but certainly not for all of them.
>   (E.g., the dashboard widget engine has somewhat finegrained
>   control, whereas the Windows Vista sidebar engine doesn't seem
>   to.)
> I'd like to see discussion of this some time soon, and will follow
> up with some examples -- the risky techniques are really all over
> the place.  Having anonymized descriptions of some example flaws and
> the attacks that work against them would probably be a useful thing
> for such a security considerations section.

Yes, I agree with this too.
Received on Friday, 14 December 2007 19:07:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:08 UTC