<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 12/03/2013 16:45, Tom Van Cutsem a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAKDfNj8-ytcDOjNoTbb68Mm1N8nkw7C+oVQXXPyRiDd+YAartw@mail.gmail.com"
      type="cite">Hi Nathan,
      <div><br>
      </div>
      <div>
        <div class="gmail_quote">2013/3/10 Nathan Wall <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:nathan.wall@live.com"
              target="_blank">nathan.wall@live.com</a>></span><br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            Given that `defineProperty` uses properties on the prototype
            of the descriptor[1] and `getOwnPropertyDescriptor` returns
            an object which inherits from `Object.prototype`, the
            following use-case is volatile:<br>
            <br>
                function copy(from, to) {<br>
                    for (let name of Object.getOwnPropertyNames(from))<br>
                        Object.defineProperty(to, name,<br>
                            Object.getOwnPropertyDescriptor(from,
            name));<br>
                }<br>
            <br>
            If a third party script happens to add `get`, `set`, or
            `value` to `Object.prototype` the `copy` function breaks.<br>
          </blockquote>
          <div><br>
          </div>
          <div>To my mind, the blame for the breakage lies with
            `Object.prototype` being mutated by the third-party script,
            not with property descriptors inheriting from
            Object.prototype. Thus, a fix for the breakage should
            address that directly, rather than tweaking the design of
            property descriptors, IMHO.</div>
        </div>
      </div>
    </blockquote>
    I agree.<br>
    <br>
    As Object.prototype-jacking threats are discussed more and more
    recently, I'd like to take a step back and "meta-discuss" JavaScript
    threats.<br>
    <br>
    Currently, by default, any script that run can mutate the
    environment it is executed in (it can be fixed by sandboxing with
    things like Caja [1] and soon the module loader API used with
    proxies [2], but even then, there could be leaks of native
    built-ins).<br>
    The first (security) decision any JavaScript application should make
    would be to freeze all built-ins like SES [3][4] does. (In the
    future, it could even make sense to add a CSP [5] directive for
    that)<br>
    If necessary, the application can first enhance the environment by
    adding polyfills/libraries and such, but that's pretty much the only
    thing that's acceptable to run before freezing everything.<br>
    <br>
    Given that freezing all built-ins (after polyfills) is a reasonable
    thing to do, I think JavaScript threat should be considered serious
    only if applicable assuming the environment is already frozen.<br>
    It naturally rules out threats related to property descriptors
    inheriting from Object.prototype or anything looking like "what if
    an attacker switches Array.prototype.push and Array.prototype.pop?"<br>
    <br>
    David<br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="http://code.google.com/p/google-caja/">http://code.google.com/p/google-caja/</a><br>
    [2] <a class="moz-txt-link-freetext" href="http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders">http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders</a><br>
    [3] <a class="moz-txt-link-freetext" href="http://code.google.com/p/es-lab/wiki/SecureEcmaScript">http://code.google.com/p/es-lab/wiki/SecureEcmaScript</a><br>
    [4]
    <a class="moz-txt-link-freetext" href="http://code.google.com/p/es-lab/source/browse/#svn%2Ftrunk%2Fsrc%2Fses">http://code.google.com/p/es-lab/source/browse/#svn%2Ftrunk%2Fsrc%2Fses</a><br>
    [5]
<a class="moz-txt-link-freetext" href="https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html">https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html</a><br>
  </body>
</html>