On Nov 25, 2009, at 1:33 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 1:25 PM, Maciej Stachowiak <[email protected]>
wrote:
On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak
<[email protected]> 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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
