Le 27/07/2014 13:35, Peter van der Zee a écrit :
On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller <erig...@google.com> wrote:
Hi Peter, what is the security issue you are concerned about?
Unless `Reflect` is completely sealed out of the box, you can never
know whether properties on it are the actual built-ins. That's all.
You can deeply freeze it yourself before any other script accesses it.
Even without doing so, let's say Reflect is not sealed.
If you change it yourself (by code you wrote or imported), you know what
to expect (or you didn't audit code you import, but them, you also know
you can only expect the worst).
If you don't change Reflect yourself, then it's third-party code which
is. But then, why did you let this third-party code access to the
capability of modifying the built-ins?
You could set up a proxy in your own domain, fetch thrid-party scripts
from there and serve them to your own domain confined (with Caja or else).
My point being that there are ways to prevent any non-trusted scripts
from modifying Reflect (assuming you stay away from script@src which
doesn't allow any form of confinment on the imported script)
For ES6, I'm not clear yet on how the module loader will work with
regards to cross-domain scripts. I believe part of the web platform
security model relies on a page not being able to read the content of
thrid-party scripts it imports via script@src (IIRC because some
websites send private data based on cookies in such scripts, so being
able to read the content of such scripts would lead to terrible data
leakage).
Does the module loader preserves such a guarantee?
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
