<div dir="ltr"><div>The one qualification everyone should be aware of is that if they simply freeze these themselves, rather than using the tamper-proofing abstractions defined by SES[1][2], then they will suffer from the override mistake[3] and conventional code such as the following will break:<br>
</div><div style><br></div><div style>  function Point(x, y) {</div><div style>    this.x = x;</div><div style>    this.y = y;</div><div style>  }</div><div style>  Point.prototype.toString = function() {</div><div style>
    return '<' + x + ',' + y + '>';</div><div style>  };</div><div style><br></div><div style>This normal looking assignment to Point.prototype.toString fails because Point.prototype inherits from Object.prototype, on which toString is a non-writable non-configurable data property.</div>
<div style><br></div><div style>[1] <a href="https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#466">https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#466</a></div>
<div style>[2] <a href="https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#869">https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#869</a></div>
<div style>[3] <a href="http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake">http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake</a></div><div style><br></div><div style><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 13, 2013 at 7:18 AM, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">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">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Le 12/03/2013 16:45, Tom Van Cutsem a
      écrit :<br>
    </div><div class="im">
    <blockquote type="cite">Hi Nathan,
      <div><br>
      </div>
      <div>
        <div class="gmail_quote">2013/3/10 Nathan Wall <span dir="ltr"><<a 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></div>
    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 href="http://code.google.com/p/google-caja/" target="_blank">http://code.google.com/p/google-caja/</a><br>
    [2] <a href="http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders" target="_blank">http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders</a><br>
    [3] <a href="http://code.google.com/p/es-lab/wiki/SecureEcmaScript" target="_blank">http://code.google.com/p/es-lab/wiki/SecureEcmaScript</a><br>
    [4]
    <a href="http://code.google.com/p/es-lab/source/browse/#svn%2Ftrunk%2Fsrc%2Fses" target="_blank">http://code.google.com/p/es-lab/source/browse/#svn%2Ftrunk%2Fsrc%2Fses</a><br>
    [5]
<a href="https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html" target="_blank">https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html</a><br>
  </div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div>