[webkit-dev] innerStaticHTML

[Adam Barth]

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.

> 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.

> 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.

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?

Adam