[webkit-dev] Best way to disable JavaScript

[Adam Barth]

On Tue, Mar 19, 2013 at 12:48 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> From other discussion on the list, it seems there are two possible ways to
> disable JavaScript execution without breaking client, user or extension
> scripts:
>
> (1) "Parser Strip" - strip scripting constructs such as <script> tags, event
> listener attributes, and javascript: URLs at parse time.
> (2) "Block Main World" - disable scripting at runtime, but only for the main
> world, and ensure that all non-page script runs in a separate isolated
> world.
>
> The message below discusses some possible implementation mistake risks of
> one approach, but I thought it might be useful to enumerate the observable
> differences in behavior between the two approaches, assuming for the time
> being they are implemented perfectly. Here is a list, without at this time
> judging which behavior is better or worse:
>
> (These all assume we're in the "scripting disabled" state)
>
> Parser Strip                            | Block Main World
> ----------------------------------------|-------------------------------------------
> Scripting constructs don't show up in   | Scripting constructs show up
> normally in
> Web Inspector                           | Web Inspector
> ----------------------------------------|-------------------------------------------
> Extensions can cause script to run in   | Extensions cannot run script in
> the main
> the main world via <script>, onfoo, or  | world.
> href="javascript:"                      |
> ----------------------------------------|-------------------------------------------
> When plugins are enabled but javascript | When plugins are enabled but
> javascript is
> is not, plugins can execute script      | not, plugins cannot execute script
> ----------------------------------------|-------------------------------------------
> When scripting is disabled only for some| When scripting is disabled only
> for some
> frames, manipulating the DOM of a frame | frames, manipulating the DOM of a
> frame
> with script disabled may cause script to| with script disabled will not
> cause script
> run there.                              | to run there.
> ----------------------------------------|-----------------------------------------------
> Copying markup from a script-disabled   | Copying markup from a
> script-disabled
> frame into a script-enabled context     | frame into a script-enabled
> context may
> cannot cause script to run.             | cause script to run (unless the
> code doing
>                                         | the copying strips scripting
> constructs).
> ----------------------------------------|-----------------------------------------------
> Ditto above for adopting nodes.         | Ditto above for adopting nodes.
> ----------------------------------------|-----------------------------------------------
>
> That's all I can think of offhand. Are there any other observable behavior
> differences?

As I wrote in my original reply, it's not possible to implement
Content-Security-Policy correctly without blocking scripts from
executing at runtime.

Another observable consequence is that moving to a parser-stripping
implementation would break a number of Chromium WebKit APIs including,
but not limited to, the following:

1) WebKit::WebPermissionClient::allowScript
2) WebKit::WebPermissionClient::didNotAllowScript

In case it's not clear from this message (and my previous messages), I
object to this change.

Adam


> On Mar 17, 2013, at 8:26 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>
> Hi folks.
>
> Currently, we have two different ways to disable JavaScript execution:
>
> (1) Paste / Drag n Drop / editing: Remove script elements and script
> attributes from untrusted source markup at parse time.
>
> (2) JavaScript disabled setting / Content Security Policy: Check settings
> and/or CSP at runtime.
>
> There are problems with mode (2):
>
> * It breaks features that are implemented in JavaScript.
>
> The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
> autofill all run JavaScript. This means that they break when users disable
> JavaScript.
>
> As a defense against phishing attacks, mail clients and other web content
> readers disable JavaScript. This means that they can't implement pieces of
> their UI in JavaScript.
>
> (FWIW, WebKit violates the CSP specification in this regard: "Enforcing a
> CSP policy should not interfere with the operation of user-supplied scripts
> such as third-party user-agent add-ons and JavaScript bookmarklets.")
>
> * It subjects users to XSS attacks.
>
> Runtime checking mode leaves inert JavaScript in the untrusted document.
> This is a risky proposition. Operations that clone or adopt nodes from the
> untrusted document unwittingly re-vivify that inert JavaScript, subjecting
> the user to attack. Experience shows that this is a difficult programming
> model to get right.
>
> * It's hard to verify.
>
> We have 18 different call sites to canExecuteScripts() in WebKit, not
> counting the call sites that pertain to plug-ins. Are you confident we've
> caught all the right places? Do you know if the feature you just added needs
> to call canExecuteScripts()?
>
> * It's two different ways to do the same thing.
>
> Simplicity is a goal of the WebKit project.
>
>
> Proposal:
>
> If -- for any reason -- JavaScript is disabled in a given document, the
> document parser will elide all JavaScript. This means that runtime checks
> can be removed.
>
> One potential downside to this proposal is that it changes the document's
> internal structure. Since the changes are not generally observable, since
> they only take place when we're already making much bigger changes by
> preventing whole scripts from running, and since we haven't seen any
> compatibility problems from our paste / drag n drop / editing behavior in
> this regard, I think this downside is acceptable.
>
> Another potential downside is that CSP errors will be reported at parse time
> instead of runtime. FWIW, some authors might see this as an upside.
>
> Any objections?
>
> Thanks,
> Geoff
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>