Re: Widget Security

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.)

Agree.

> 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:

  <http://www.w3.org/TR/wsc-threats/>


> 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