No subject
Mon Jan 28 08:41:14 PST 2013
(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?
Note: there's also the possibility of doing both of these, which will result in a mix of the above behaviors.
Regards,
Maciej
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
--Boundary_(ID_0Vu/ONM/qiYHn7QyGbejRQ)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><br></div><div>=46rom other discussion on the =
list, it seems there are two possible ways to disable JavaScript =
execution without breaking client, user or extension =
scripts:</div><div><br></div><div>(1) "Parser Strip" - strip scripting =
constructs such as <script> tags, event listener attributes, and =
javascript: URLs at parse time.</div><div>(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.</div><div><br></div><div>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:</div><div><br></div><div>(These all =
assume we're in the "scripting disabled" =
state)</div><div><br></div><div><font face=3D"Courier">Parser Strip =
=
| Block Main World</font></div><div><font =
face=3D"Courier">----------------------------------------|----------------=
---------------------------</font></div><div><font =
face=3D"Courier">Scripting constructs don't show up in =
| </font><span style=3D"font-family: Courier;">Scripting constructs =
show up normally in</span></div><div><font face=3D"Courier">Web =
Inspector =
| Web Inspector</font></div><div><span =
style=3D"font-family: =
Courier;">----------------------------------------|-----------------------=
--------------------</span></div><div><font face=3D"Courier">Extensions =
can cause script to run in | Extensions cannot run script in the =
main</font></div><div><font face=3D"Courier">the main world via =
<script></font><span style=3D"font-family: Courier;">, onfoo, or =
| </span><span style=3D"font-family: =
Courier;">world.</span></div><div><span style=3D"font-family: =
Courier;">href=3D"javascript:" =
|</span></div><div><span =
style=3D"font-family: =
Courier;">----------------------------------------|-----------------------=
--------------------</span></div><div><font face=3D"Courier">When =
plugins are enabled but javascript | </font><span =
style=3D"font-family: Courier;">When plugins are enabled but javascript =
is</span></div><div><font face=3D"Courier">is not, plugins can execute =
script | not, p</font><span style=3D"font-family: =
Courier;">lugins cannot execute script</span></div><div><div><span =
style=3D"font-family: =
Courier;">----------------------------------------|-----------------------=
--------------------</span></div></div><div><div><font =
face=3D"Courier">When scripting is disabled only for =
some| </font><span style=3D"font-family: Courier;">When scripting =
is disabled only for some</span></div><div><font face=3D"Courier">frames, =
manipulating the DOM of a frame | </font><span style=3D"font-family: =
Courier;">frames, manipulating the DOM of a frame</span></div><div><font =
face=3D"Courier">with script disabled may cause script =
to| </font><span style=3D"font-family: Courier;">with script =
disabled will not cause script</span></div><div><font face=3D"Courier">run=
there. =
</font><font face=3D"Courier"> =
| </font><span style=3D"font-family: Courier;">to</span> <span =
style=3D"font-family: Courier;">run there.</span></div><div><span =
style=3D"font-family: =
Courier;">----------------------------------------|-----------------------=
------------------------</span></div></div><div><span =
style=3D"font-family: Courier;">Copying markup from a script-disabled =
| </span><span style=3D"font-family: Courier;">Copying =
markup from a script-disabled</span></div><div><span style=3D"font-family:=
Courier;">frame into a script-enabled context =
| </span><span style=3D"font-family: Courier;">frame into a =
script-enabled context may</span></div><div><span style=3D"font-family: =
Courier;">cannot cause script to run. =
| cause script to run (unless the code =
doing </span></div><div><span style=3D"font-family: =
Courier;"> =
=
| the copying strips scripting =
constructs).</span></div><div><div><span style=3D"font-family: =
Courier;">----------------------------------------|-----------------------=
------------------------</span></div></div><div><span =
style=3D"font-family: Courier;">Ditto above for adopting nodes. =
| </span><span style=3D"font-family: =
Courier;">Ditto above for adopting nodes.</span></div><div><div><span =
style=3D"font-family: =
Courier;">----------------------------------------|-----------------------=
------------------------</span></div></div><div><span =
style=3D"font-family: Courier;"><br></span></div><div><span =
style=3D"font-family: =
Courier;"><br></span></div><div><br></div><div>That's all I can think of =
offhand. Are there any other observable behavior =
differences?</div><div><br></div><div>Note: there's also the possibility =
of doing both of these, which will result in a mix of the above =
behaviors.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><b=
r></div><div><br></div><br><div><div>On Mar 17, 2013, at 8:26 PM, =
Geoffrey Garen <<a =
href=3D"mailto:ggaren at apple.com">ggaren at apple.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;">Hi folks.<br><br>Currently, we have two =
different ways to disable JavaScript execution:<br><br>(1) Paste / Drag =
n Drop / editing: Remove script elements and script attributes from =
untrusted source markup at parse time.<br><br>(2) JavaScript disabled =
setting / Content Security Policy: Check settings and/or CSP at =
runtime.<br><br>There are problems with mode (2):<br><br>* It breaks =
features that are implemented in JavaScript.<br><br>The Web Inspector, =
bookmarklets, extensions, Safari Reader, and Safari autofill all run =
JavaScript. This means that they break when users disable =
JavaScript.<br><br>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.<br><br>(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.")<br><br>* =
It subjects users to XSS attacks.<br><br>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.<br><br>* It's hard to verify.<br><br>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()?<br><br>* It's two different ways to do the same =
thing.<br><br>Simplicity is a goal of the WebKit =
project.<br><br><br>Proposal:<br><br>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.<br><br>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.<br><br>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.<br><br>Any =
objections?<br><br>Thanks,<br>Geoff<br>___________________________________=
____________<br>webkit-dev mailing list<br><a =
href=3D"mailto:webkit-dev at lists.webkit.org">webkit-dev at lists.webkit.org</a=
><br><a =
href=3D"https://lists.webkit.org/mailman/listinfo/webkit-dev">https://list=
s.webkit.org/mailman/listinfo/webkit-dev</a></div></blockquote></div><br><=
/body></html>=
--Boundary_(ID_0Vu/ONM/qiYHn7QyGbejRQ)--
More information about the webkit-dev
mailing list