<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Le 02/02/2012 15:34, Russell Leggett a écrit :
    <blockquote
cite="mid:CAC6Dk8cHgqD-4KWT0=FrT2K826XxAXWSekZPd-BRVRnpYMSMfA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Wed, Feb 1, 2012 at 5:41 PM, David
        Bruant <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:bruant.d@gmail.com">bruant.d@gmail.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Hi,<br>
          <br>
          I have claimed here a couple of times, that in a JavaScript
          application<br>
          containing code from different parties, the first to run is
          the one that<br>
          is in position to make decisions about security of the overall<br>
          application (freezing the primordials for a defender or
          monkey-patching<br>
          them if you're an attacker). I still have no proof (I feel
          it's coming<br>
          though) about it, but a strong intuition.<br>
          <br>
          Assuming this is true, then, on the web, one has to make sure
          that her<br>
          protecting script runs first. How to ensure this, though?
          There is<br>
          always a risk that with an XSS an attacker scripts runs before
          the<br>
          protecting one.<br>
          I think I have found an answer and it is: with Content
          Security Policy<br>
          (CSP) [1].<br>
          <br>
          CSP introduces a "script-src" directive [2] allowing only a
          whitelist of<br>
          script URLs to be "fetchable" as script@src. Moreover, by
          default,<br>
          inline scripts (in scripts or as on* attributes) won't
          execute.<br>
          <br>
          Consequently, in browsers that support the script-src CSP
          directive<br>
          (script whitelisting even reduced to one element and the "If<br>
          'unsafe-inline' is not in allowed script sources" rule), one
          can enforce<br>
          running her script first.<br>
          The restriction is even stronger, because the whitelisted
          script is just<br>
          the only one to run.<br>
          <br>
        </blockquote>
        <div> </div>
        <div style="">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</div>
      </div>
    </blockquote>
    That's why I included the browser support at the end of my initial
    message (you stripped that part)<br>
    <br>
    <blockquote
cite="mid:CAC6Dk8cHgqD-4KWT0=FrT2K826XxAXWSekZPd-BRVRnpYMSMfA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div style=""> and beyond that, it just seems like in practice,
          it is unlikely to make the difference between running first
          and not running first.</div>
      </div>
    </blockquote>
    What is unlikely to make the difference?<br>
    <br>
    <br>
    <blockquote
cite="mid:CAC6Dk8cHgqD-4KWT0=FrT2K826XxAXWSekZPd-BRVRnpYMSMfA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div style="">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.</div>
      </div>
    </blockquote>
    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.<br>
    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])<br>
    <br>
    <br>
    <blockquote
cite="mid:CAC6Dk8cHgqD-4KWT0=FrT2K826XxAXWSekZPd-BRVRnpYMSMfA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div style="">I think I said this before and you mentioned the
          title tag. <br>
          (snip)</div>
      </div>
    </blockquote>
    <div style="">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).<br>
    </div>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAC6Dk8cHgqD-4KWT0=FrT2K826XxAXWSekZPd-BRVRnpYMSMfA@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div style="">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.<br>
        </div>
      </div>
    </blockquote>
    Inline scripts which have access to the document object (which can
    easily be ab-used for phishing)?<br>
    <br>
    David<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object">http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object</a><br>
    'document' property is [unforgeable]<br>
  </body>
</html>