Review ES6 impact

[natevw]

E.g. does the Reflect API (intro here: http://blog.keithcirkel.co.uk/metaprogramming-in-es6-part-2-reflect/) change anything? new.target? Anything else?

[Mickael-van-der-Beek]

Well both Symbol and Reflect are not exposed to the Evel sandbox scope so that shouldn't change anything.

Or did you ask the question in case one or both of those API were to be exposed to the sandbox?

[natevw]

@Mickael-van-der-Beek That Symbol and Reflect aren't exposed is really a bug (now filed as #26), although certainly with the latter it's probably good that it can reviewed a bit more

[natevw]

Finally started diving into this, although only a bit. So far the couple things that stood out as needing a closer look would be Reflect.construct and Symbol.for but both of those seem relatively harmless so far.

Also need to review what surfaces Symbol.species / Symbol.iterator and such would give access to.

[natevw]

Also new.target seems to be harmless in my quick testing:

(function () {
  function Foo() {
    return new.target.prototype.constructor.constructor.constructor;
  }
  return new Foo();
})()

still returns evel.Function as it should.

[natevw]

What about AsyncFunction from Object.getPrototypeOf(async function(){})? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncFunction

[Mickael-van-der-Beek]

@natevw Those are indeed leaked through the syntax as well. e.g:

(function*(){}).constructor('yield this')().next().value.alert(1)

and

(async function(){}).constructor('this.alert(1);')()

Even though code execution is possible, it's not possible to pop an alert box due to the iframe not being attached to the DOM.

To my knowledge, it's also not possible to escape the iframe itself.

[Mickael-van-der-Beek]

It also seems like Caja has had similar issues recently: http://blog.bentkowski.info/2017/11/yet-another-google-caja-bypasses-hat.html