How to ensure that your script runs first in a webpage

David Bruant bruant.d at gmail.com
Thu Feb 2 07:00:48 PST 2012


Le 02/02/2012 15:34, Russell Leggett a écrit :
> On Wed, Feb 1, 2012 at 5:41 PM, David Bruant <bruant.d at gmail.com 
> <mailto: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
That's why I included the browser support at the end of my initial 
message (you stripped that part)

> and beyond that, it just seems like in practice, it is unlikely to 
> make the difference between running first and not running first.
What is unlikely to make the difference?


> 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.
You're making me realize that in (CSP-disabled) browsers, running first 
may not be enough. Considering inline scripts, these can run after you, 
but can be hurtful anyway.
For instance, even if you run first, you can't prevent later inline 
scripts from accessing the "document" property of the global object (it 
is non-configurable and the spec is the one saying so [1])


> I think I said this before and you mentioned the title tag.
> (snip)
Regardless of before of after the title tag, if we want run first, it 
seems necessary (in CSP-disabled browsers) to have an inline synchronous 
<script>. This is annoying for performance. However, it seems that CSP 
allows not only to safely run any JavaScript in the page, but to do it 
with performance as well (actually, a web browser, when seeing only one 
URL in the script-src directive could decide to fetch the js file even 
before the HTML has finished being downloaded).



> 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.
Inline scripts which have access to the document object (which can 
easily be ab-used for phishing)?

David

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
'document' property is [unforgeable]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120202/73b5780e/attachment.html>


More information about the es-discuss mailing list