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

[whatwg] Content Restrictions

From: Hallvord Reiar Michaelsen Steen <hallvord@hallvord.com>
Date: Tue, 31 Jan 2006 02:49:03 +0900
Message-ID: <43DED01F.30945.35ECEFC9@hallvord.hallvord.com>
On 27 Jan 2006 at 12:29, Gervase Markham wrote:

> I'd like to present to the group for comment my "Content Restrictions"
> proposal. http://www.gerv.net/security/content-restrictions/

Hi Gerv,
first of all: it's great to get some fresh ideas here. You've seen 
the earlier thread and it didn't get enough brainstorming going.. 

My colleage Sigbj?rn had some thoughs, forwarding with his 
permission:

> ------- Forwarded message -------
> From: "Sigbj?rn Vik"
> Subject: Re: [Evil-knights] Fwd: [whatwg] Content Restrictions
> Date: Fri, 27 Jan 2006 22:18:54 +0900
> 
> I support the idea, but not the granularity of it. The author is trying to
> do the same thing as the webmails that fail, by specifying exactly what
> can and cannot be allowed. Even if cookie access is disallowed, a script
> would be able to call some other function in a parent frame which is
> allowed this access, and thus get the cookies anyhow. The fine granularity
> open up for a lot more security issues and creativity of exploiters, which
> would make web browsers reluctant to implement it. The complexity of
> allowing scripts access to only parts of the DOM will also make web
> browserts reluctant to implement it. Not to mention the difficulty for
> web-authors in understanding the security implications of the various
> choices.
> 
> Instead, I would suggest just three type of restrictions: script, style,
> embedded content (anything loaded from a 3rd party server). I'd even
> suggest that each one of them is off only, no values or granularity
> allowed.
> 
> Also, meta tags need to be allowed and take precedence over http headers.
> (To make it possible to override things for a given page without having to
> have access to the server.)

I generally agree with those comments (except the META tag 
statement). There can be quite some security in simplicity :-)

You replied to Alexey Feldgendler:

> 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

But actually the details of your approach are powerful enough to have 
other use cases, so you're covering similar ground to what Alexey and 
I were discussing.

The main complexity in doing anything in this area is probably the 
flexibility of JavaScript. I don't think any UA really keeps track of 
the origin of each script - they are all associated with the domain 
of the page they are running in, and that's how same-origin security 
policies are applied. However, trying to make that more granular is a 
major headche. That's why I really like your approach of (as far as I 
can see) defining policies that are applied to all scripts in the 
document. Of course it limits what sort of scripting the webmaster 
can deploy along with the possibly insecure scripts, but it is a very 
interesting angle.
-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/
Received on Monday, 30 January 2006 09:49:03 UTC

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