Re: Tag to disable unwanted features?

At 05:28 AM 9/28/2007, David Woolley wrote:

>Lincoln Yeoh wrote:
>>
>>Any suggestions for doing a similar thing without violating the 
>>existing language model that will actually work and be fairly 
>>simple to implement?
>
>
>I would say the real solution to your requirement is to use object 
>elements to contain the unsafe HTML, they can then provide a very 
>clear security boundary.  The browser content origin rules can then 
>provide the protection.  I suspect support for HTML objects is 
>currently poor, but support for your proposal is currently non-existent.

But how would the end marker be made unambiguous? I don't see a way 
around requiring that the end marker must have the same random secret 
string as the start marker (unless you require a separate http 
request for the unsafe content - which would probably be bad for performance).

Will that necessarily violate the language model? Are there really no 
other alternatives?


>If you want to try, I think there is a responsibility on the content 
>management system to canonicalise the HTML, and remove all unknown 
>attributes.  That way, the user should not be able to trick the 
>browser's parser.  There are HTML parsing libraries, even if many 
>content management systems use very shallow, tag soup, type parsing.

That only works if the HTML parsing libraries parse the things 
essentially the same ways the different browsers parse - with respect 
to security problems (whether publicly known or unknown).

Would making such a library be easier and less error prone than being 
able to tell the browser - "from now on, there's _no_ javascript, 
till I say "Simon Says a12xf5hv45".

If you are gmail, or myspace, or some financial site collating 
information from around the world, you will have content from 
untrusted 3rd parties, which you would like to send to your users in 
HTML (and not plain text), but a _safer_ HTML.

Presumably you would still want YOUR active content to work (if 
allowed by the user/browser), but you would want the 3rd party 
content to be "dead".

>Another problem that you may have is that authors of the third party 
>content may well convince users that browsers that implement your 
>mechanism are broken, because they don't render their material as 
>well as less restricted browsers.  This has always been the problem 
>in getting browsers to follow standards.

Yes, the authors of the third party content will convince some users 
to buy pills from them too :).

This is not going to be 100% solution.

>If you are sure that you want something that violates element 
>structure, but are confident that you can protect the lexical 
>structure, processing instructions may be more appropriate, but I'm 
>not really sure that that is their true purpose.

I don't want something that violates element structure! I've already 
asked for suggestions that won't violate stuff.

I am not an expert on element structure, nor am I an expert in 
writing browsers.

I basically want the equivalent of _brakes_ for html. I'm not that 
bothered on what form they take as long as they work well.

Right now, with current HTML, to "stop the car" you need to make sure 
all the relevant "Go Faster" elements are disabled (I don't even know 
how many there are), and every year or so people will probably be 
adding new elements that existing code or parsing libraries may not 
even know about.

In contrast, if we did have brakes, the brakes _might_ still work for 
some browsers. It's not 100%, but a sane browser could presumably 
still pretend to not have those new features between the brake 
tags/elements/or whatever whoever wants to call them.

I believe this would make things a lot more resilient.

It bothers me that "a W3C standards compliant car has no brakes", and 
typically "users" are just told to drive safely, and "car" makers are 
told that their cars must raise security exceptions when "stuff" happens.

Oh well, I hope that sandboxing thing works out in the end.

Link.

Received on Friday, 28 September 2007 15:37:58 UTC