[whatwg] Sandboxing ideas

Le 2007-05-14 ? 17:11, Alexey Feldgendler a ?crit :

> On Mon, 14 May 2007 22:29:57 +0200, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
>
>> If you want the sandbox to degrade securely in older browsers,  
>> then this is not a solution. But I don't think there's a nice  
>> solution to that anyway.
>
> This does degrade securely, doesn't require separate HTTP requests,  
> and maintains human readability.
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-December/ 
> 005301.html

Quoted from there:

> 7.1. There are new elements: <safe-script>, <safe-object>, <safe- 
> iframe>
> (did I forget something?). They are equivalent to their "unsafe"
> counterparts, except that the existing browsers simply ignore them.  
> HTML
> cleaners should replace <script> with <safe-script> and likewise.
>
> 7.2. HTML event handler attributes are mangled likewise: safe- 
> onclick, for
> example. Note that this doesn't affect the names of DOM properties  
> like
> element.onclick.
>
> 7.3. A new URI scheme is introduced: "safe-javascript:". Likewise.

People are already struggling to remove all scripts from HTML  
snippets. I don't think finding all these occurrence and replacing  
them is going to be much better. Also, you'd need safe-style="" and  
<safe-style> too, since IE can embed javascript expressions into  
style rules. (And now lets hope IE does not allow expression elsewhere.)

<sandbox>, as suggested above, does not degrade securely in my  
opinion, not without  complex preprocessing with workarounds for  
every browser's features. Today's browsers don't understand the  
<sandbox> element and will execute enclosed scripts with full access  
to the page, and I doubt many web developers will get that  
preprocessing right (so much things to think about).


I my last reply:

> Le 2007-05-14 ? 16:19, Alexey Feldgendler a ?crit :
>
>> Not to mention that data: URIs are ugly, wasteful (because of the  
>> BASE64 encoding), cannot be read and written by humans directly,  
>> and have maximum length problems in some implementations.
>
> I think you can use HTTP compression to work around the inflated  
> size of Base64, but otherwise it certainly is ugly and not human  
> readable.

Thinking more about it now, you don't need Base64 encoding. This can do:

     <iframe src="data:text/html;charset=utf-8,
       &lt;!DOCTYPE HTML&gt;
       &lt;p&gt;&quot;Unsafe&quot; content here:&lt;/p&gt;
       &lt;script&gt;
         document.write(window.parent.location)
       &lt;/script&gt;
     "></iframe>

(Tested to work in Safari and Camino.)

The interesting bit is that a failure to correctly encode quotes  
within the inner document URL is an easy-to-notice mistake as it'll  
cause the page to behave badly visually, making it unlikely that web  
developers forget about it and leave holes for attackers to insert  
other attributes or tags in the page's content.

This principle could be transposed to <sandbox>, where it could be  
defined as taking the unsafe HTML content from an attribute. And the  
best part: you don't need anything else like the safe-* substitutions  
as suggested earlier for <sandbox>:

     <sandbox type="text/html" content="
       &lt;p&gt;&quot;Unsafe&quot; content here:&lt;/p&gt;
       &lt;script&gt;
         document.write(window.parent.location)
       &lt;/script&gt;
     ">
        Alternative, possibly degraded but safe content for older  
browsers.
     </sandbox>

This would allow authors to make sandboxes that degrade both  
"securely" (as shown above) and "unsecurely" (by placing the same  
content as alternative content, exposing the whole page to the script  
for older browsers while keeping it sandboxed on the new ones).


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/

Received on Monday, 14 May 2007 20:13:43 UTC