Re: Seamless iframes + CSS3 selectors = bad idea

On Dec 8, 2009, at 1:30 AM, Adam Barth wrote:

> On Tue, Dec 8, 2009 at 1:23 AM, Daniel Glazman <daniel@glazman.org>  
> wrote:
>> 1. act at the injection level; make cross-linking of stylesheets
>>   impossible. That would kill many web-based applications and I
>>   certainly do not support that.
>
> I'm not sure this would solve the problem given the existence of
> inline style declarations.
>
>> 2. make attribute selectors in cross-linked stylesheets fail or reply
>>   silly things; ugly, not my choice, see 4 below
>
> Again, this seems problematic because of inline style.
>
>> 3. kill attribute selectors; will never happen, period.
>
> Can you elaborate on this point?  Why is this off the table?

As an implementor, I don't think the scope of the problem described so  
far would convince me to completely remove a longstanding and useful  
feature. And they are useful - check out how much attribute selectors  
are used in WebKit's UA stylesheets for instance. A narrowly tailored  
limit might be viable.

>
>> 4. add a declarative option to <link> and <style> elements to say
>>   the CSS parser should be in a "sandboxed" mode, dropping some
>>   selectors, properties and values. From our CSS WG point of view,
>>   it's almost a profile of CSS. That is doable modulo the fact
>>   browser vendors accept to implement it; the way to do it is then
>>   to write a spec detailing a "CSS Secure Profile" (that's your task
>>   guys), have HTML add something to <link> and <style> for sandboxed
>>   stylesheets, and finally pray a bit you'll see it implemented  
>> before
>>   the end of the next decade.
>
> I don't understand why that would help.  Wouldn't the attacker simply
> load their stylesheet in a non-sandboxed mode?

I think the idea is that a site voluntarily including untrusted (e.g.  
user-provided) CSS could include it in "sandboxed" mode.

Regards,
Maciej

Received on Tuesday, 8 December 2009 15:14:29 UTC