[webkit-dev] innerStaticHTML

[Maciej Stachowiak]

On Nov 25, 2009, at 1:33 PM, Adam Barth wrote:

> On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>> On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
>>> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak  
>>> <mjs at apple.com> wrote:
>>>> On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
>>>>> Maybe we should have a DOM API called
>>>>> webkitJailChildren("no-script-for-you") on Node that prevents  
>>>>> future
>>>>> children from running script.  Making it a DOM API prevents  
>>>>> authors
>>>>> from trying to turn the feature on with markup.
>>>>
>>>> Interesting idea. This seems potentially trickier to implement  
>>>> than just
>>>> innerStaticHTML, since nearly every method that mutates the DOM  
>>>> will have
>>>> to
>>>> check jail status. innerStaticHTML could be limited in scope to  
>>>> only
>>>> operations that happen as part of parsing.
>>>
>>> Instead of checking every DOM mutation, we could just walk the  
>>> parent
>>> pointers before executing a script to see if an ancestor is jailed.
>
> I don't have a complete design in mind.  I could try to write up a
> design document.

Sounds like we could use one given the potential complications.

>
>> A few thoughts:
>>
>> 1) Presumably we'd want to block instantiation of plugins and Java  
>> applets
>> too, or the scripting restriction becomes toothless. Perhaps also  
>> iframes,
>> unless the scripting restriction is intended to propagate across  
>> frame
>> boundaries.
>
> Yes.  Also the <base> element.  Essentially, all the same APIs that
> are currently restricted by the XSSAuditor.
>
>> 2) Capturing all points at which script execution occurs and  
>> tracing them
>> back to the originating element may be tricky. javascript: URIs are  
>> one
>> potentially subtle example. By the time the JavaScript for those gets
>> executed, I believe we no longer know the originating element, the  
>> way the
>> code is currently structured.
>
> The way I would do this is to teach HTMLAnchorElement and friends not
> to hand off JavaScript URLs to FrameLoader if their parent is jailed.
> I'm not sure how many such interception points we'd need.

Not sure either. Two others I can think of are SVGAElement and  
HTMLFormElement.

>
>> 3) It seems like the rule "don't execute JS" might not be quite  
>> what is
>> desired, since it would (presumably) prevent the parent itself from  
>> using
>> event listeners on nodes in the jail. IMO the best treatment for  
>> event
>> listeners would be to prevent them from being created by  
>> attributes, rather
>> than to prevent them from executing.
>
> Agreed.  We'd want to stop inline event listeners from being created
> on jailed nodes.
>
>> 4) Do we need to strip or rename id, name and class values to prevent
>> interference with the containing page's use of getElementById() and  
>> such?
>> Caja does.
>
> I think this is an order of magnitude less important that direct
> script execution.  There are going to be advanced use cases for which
> Caja is the right answer.

Caja wants to let you actually run script in the jail without  
interfering with the containing page - I definitely don't think we  
should target that. But preventing the content from interfering with  
the containing page seems in-scope. I agree this particular threat is  
less risky than actual script execution.

> The other way to skin this cat, by the way, is to implement the
> seamless attribute on iframes.  That gives you a similar sort of
> design using the @sandbox attribute and solves many of your above
> concerns, e.g. by creating a new namespace for @ids.  Maybe we should
> try that first or in parallel?

Indeed, it can cover some similar use cases. I don't know if it's good  
for comment sections - one iframe per comment would be quite  
heavyweight. If there is any active content *around* each comment  
(like edit or reply buttons) then you might not be able to use one for  
all of them. In such a case I think innerStaticHTML (or moral  
equivalent via jailed nodes) would be a more suitable solution. If you  
have only a small number of untrusted content regions then seamless  
iframes could be a good solution and it might be easier to be really  
confident of the implementation (since all cross-frame access of any  
kind is already doing a security check, and turning off scripting or  
plugins wholesale for a frame can be done in a very localized way).  
OTOH it would require render tree expertise to implement the layout  
aspects.

Regards,
Maciej