How to ensure that your script runs first in a webpage

Russell Leggett russell.leggett at gmail.com
Thu Feb 2 06:34:36 PST 2012


On Wed, Feb 1, 2012 at 5:41 PM, David Bruant <bruant.d at gmail.com> wrote:

> Hi,
>
> I have claimed here a couple of times, that in a JavaScript application
> containing code from different parties, the first to run is the one that
> is in position to make decisions about security of the overall
> application (freezing the primordials for a defender or monkey-patching
> them if you're an attacker). I still have no proof (I feel it's coming
> though) about it, but a strong intuition.
>
> Assuming this is true, then, on the web, one has to make sure that her
> protecting script runs first. How to ensure this, though? There is
> always a risk that with an XSS an attacker scripts runs before the
> protecting one.
> I think I have found an answer and it is: with Content Security Policy
> (CSP) [1].
>
> CSP introduces a "script-src" directive [2] allowing only a whitelist of
> script URLs to be "fetchable" as script at src. Moreover, by default,
> inline scripts (in scripts or as on* attributes) won't execute.
>
> Consequently, in browsers that support the script-src CSP directive
> (script whitelisting even reduced to one element and the "If
> 'unsafe-inline' is not in allowed script sources" rule), one can enforce
> running her script first.
> The restriction is even stronger, because the whitelisted script is just
> the only one to run.
>
>
I agree with (I think) all of what you've said here. Running first is
absolutely the key to being able to lock down and protect yourself. CSP can
clearly help you guarantee that, plus a lot more. What I don't quite
understand is the level of emphasis being placed here. CSP is not
guaranteed in all browsers, so you can't rely on it - its not exactly
something you can polyfill, and beyond that, it just seems like in
practice, it is unlikely to make the difference between running first and
not running first.

Any developer who cares enough, and knows enough, to use CSP and some
script to lock down the browser, will surely be able to protect themselves
from the tiny attack vector available if you just put the lockdown script
first in your head tag. I think I said this before and you mentioned the
title tag. Looking at the spec and testing, I noticed a few things.

Lets assume an attack where the coder allowed an unescaped variable into
the the title tag like:

    <title>${unescapedContentFromMaliciousUser}</title>

1. You can put a script tag above the title tag. This is perfectly fine
according to spec, even though it is not common practice.
2. You cannot put a script tag inside the title tag - it will not get
executed. This is also according to spec and I've tested it.
3. If the attacker tried to do a sql injection style attack and close the
<title> and follow it with a script tag like:

    <title></title><script type="text/javascript">console.log("I'm
attacking!");</script></title>

It will execute, but as long as you put your protection script first, yours
will run first.

Ultimately, while I think there is value in CSP, for sure, in this case
isn't it just easier to put your protection script all the way at the top?
I would be happy to see a counter-example.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120202/4a727a6e/attachment-0001.html>


More information about the es-discuss mailing list