CSP details (was Re: heya-ctr performance)
James Burke <jburke <at> dojotoolkit.org>
2013-05-07 03:19:22 GMT
Breaking off from other thread:
On Mon, May 6, 2013 at 7:38 PM, Eugene Lazutkin <eugene <at> lazutkin.com> wrote:
> I don't see how using scripts, or XHR correlates with eval(), or its
> derivations.
These are the ways I know of to execute external scripts:
* script tags with src elements
* getting the text of the script somehow (usually XHR, but could be
streamed, say over a web socket), then either evaling it or adding it
via a script tag with inlined content.
* importScripts in a web worker.
AMD loaders generally use (although are not required to use, and some
do not use) script src tags. The define() syntax for modules was
designed for that. If the module does not have a function wrapper+API
call, then it normally means a loader that uses XHR with eval is in
play, so the script can be fetched as text, then some auto-wrapping is
done in the loader before calling eval. eval is nice over an inlined
script tag because it can capture scope.
> Again my knowledge may be outdated, but unsafe-eval option
> was/is a separate flag from everything else. It is quite possible to
> allow eval() while prohibiting scripts, e.g., by restricting their URL
> pattern, protocol, or even disallowing them completely. If I remember
> correctly, it is quite possible to prohibit scripts with script-src,
> while keep XHR open with connect-src.
By specifying a script-src policy, eval is by default turned off
unless explicitly enabled:
https://developer.mozilla.org/en-US/docs/Security/CSP/CSP_policy_directives#script-src
"The script-src section specifies valid sources for JavaScript;
attempts to request or load scripts from other sources are not
allowed. When either the script-src or the default-src directive is
included, inline script and eval() are disabled unless you specify
'unsafe-inline' and 'unsafe-eval', respectively."
So, even though xhr could be allowed to fetch a script, it would be
inert, not very useful with the default use of script-src. They will
likely want to allow some script-src just to be able to load the
script loader itself.
The situation where a script-src based loader would not work: the user
explicitly limits script-src, explicitly enables connect-src and
explicitly enables eval. However the first thing secure JS sandbox
environments do is to disable the use of eval. And not allowing any
script-src tags seems incredibly limiting.
So while it would technically be possible to create a CSP policy that
would cause a script-src based loader to fail, it seems to go counter
to the main reasons for wanting CSP in the first place: better
security from malicious scripts. The percentage of actual real world
CSP usage will favor script loaders that do not rely on eval (which is
usually backed by XHR to fetch the scripts) to work.
James
RSS Feed