ES Native Mode proposal

David Bruant bruant.d at
Thu Sep 26 01:22:00 PDT 2013

Le 26/09/2013 09:10, Aymeric Vitte a écrit :
> There are other cases, like malicious code injection.
CSP goes a long long way in preventing these.

> I don't know if it's really feasible without redefining the DOM on top 
> of it but I feel the need since a long time, something that makes sure 
> you are using the right XMLHttpRequest or other and not a modified one.
In environments where you don't have the option of freezing all 
built-ins, running your code first allows you to keep a reference to the 
initial XMLHttpRequest.
You may then wonder: "how can I enforce running first?"
=> If you're in control of the webpage, it really is up to you to run 
trusted code *before* any other scripts. If you're building a library 
other will include at any point in time they want, hope for a standard 
environment, expect nothing.

> And something that prevents a bad script to do something like 
> setTimeout(change_globals,xxx)
The problem here is exactly the same problem than viruses.
The only reason viruses exist at all is the design mistake that led 
operating systems to consider than programs you (human being) start, run 
with the same authority than you. Indeed, any program you run can throw 
away all your files, send them over the network to whatever server, etc. 
Hence viruses.
Seriously, how did we end up in a world where Windows Vista (and later? 
I've stopped Windows) think it's a good idea to ask for a confirmation 
pretty much after any click where could would be run? If Windows has a 
way to know the second click is secure, how much harder is it to make 
sure the *first* click is secure!! This is insane!

Related is this interesting talk:
"The SkyNet Virus - Why it is Unstoppable; How to Stop it"
It's old and low-quality (video, not content), but it's really good.

In my opinion, the good question isn't "how to prevent a bad script to 
do something like ...?", but rather "how can I make sure that scripts, 
any script, can be loaded only with the authority it needs?". How did 
the bad script you're talking about above ended up with the authority to 
change globals?
CSP is a good start and says "don't run scripts that aren't 
whitelisted". You prevent scripts you haven't chosen to run at all. For 
sure, they won't change globals.
Caja and Module loader allow to run partially trusted code with 
fine-grain (object-level) control of the exact amount of authority you want.

In any case, the problem starts (and likely ends) with how code is 
loaded. When this problem is solved (and I think it pretty much is with 
CSP and Caja/Module Loader), then most script-related security problems 
are solveable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list