Le 02/02/2012 15:34, Russell Leggett a écrit :
On Wed, Feb 1, 2012 at 5:41 PM, David Bruant <[email protected]
<mailto:[email protected]>> 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@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]
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
