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"
http://www.erights.org/talks/skynet/
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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
