W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2006

[whatwg] Content Restrictions

From: Gervase Markham <gerv@mozilla.org>
Date: Mon, 30 Jan 2006 15:21:13 +0000
Message-ID: <43DE2EE9.8060401@mozilla.org>
Alexey Feldgendler wrote:
> See point 7 in my message:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-December/005301.html
> 
> It's specifically targeted at keeping decent security in older browsers.
> User agents that don't support sandboxing won't execute the scripts at all.

What problem are you trying to solve with this proposal? I'm not sure
it's the same one that I am. You are trying to solve the problem of
letting LiveJournal authors include certain types of "safe" script on
their page, when currently they aren't allowed to include any.

I'm trying to solve the problem of protecting users from XSS attacks
when there are unexpected bugs in an author's web application.

> I'm very suspicious of any security policy model that doesn't degrade
> safely. If it's anything else, it's OK to define that "older browsers
> will just ignore this". But when it's about security, the possibility of
> exceeding the defined privileges is not acceptable. 

But it's not a case of "exceeding the defined privileges". Script today
can do "anything" - but only within the browser security model. So it
can't, for example, write to your local disk. These sorts of things are
the "defined privileges" which it's not acceptable to exceed - and
neither my proposal nor yours allows exceeding them.

However, in certain cases, an author may want to *further* restrict the
capabilities of script on his page. For example, he may want to use it
as a backstop in case his web application has an XSS problem.

In this sort of scenario, it seems entirely reasonable to enumerate what
further restrictions you want to put on the script.

If we could rewrite the web again, we might start with a positive,
capabilities-based system, where every time you inserted a <script> tag
you had to define what it was _allowed_ to do. But we are where we are,
and <script> tags by default have "full" privileges. So, for backwards
compatibility, we need a restrictions model.

> There is a well-known use case: blogs, wikis, forums and other web-based
> systems that allow users enter text with markup. Many of them would like
> to allow some scripting, but because they can't tell good scripts from
> bad ones (which steal cookies, post comments on behalf of the user and
> do other nasty things), they filter out <script>...</script> completely.
> They won't benefit of the content restrictions you propose because they
> can't risk feeding unsafe content to an older browser which doesn't
> understand the restrictions.

This is not a problem I'm trying to solve.

And anyway, I don't think it's a serious security problem, because it
already has a solution - filter out <script> altogether. I've not come
across a compelling use case which says that blogs and wikis need to
allow people to insert certain sorts of script into the blogpost or wiki
page.

Gerv
Received on Monday, 30 January 2006 07:21:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:25 UTC