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.
