mjs at apple.com
Wed Nov 25 13:49:39 PST 2009
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>
>> 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
>>>>> children from running script. Making it a DOM API prevents
>>>>> 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
>>>> check jail status. innerStaticHTML could be limited in scope to
>>>> operations that happen as part of parsing.
>>> Instead of checking every DOM mutation, we could just walk the
>>> 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
>> too, or the scripting restriction becomes toothless. Perhaps also
>> unless the scripting restriction is intended to propagate across
> 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
>> 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
> I'm not sure how many such interception points we'd need.
Not sure either. Two others I can think of are SVGAElement and
>> 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
>> event listeners on nodes in the jail. IMO the best treatment for
>> 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
>> 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
More information about the webkit-dev