I have just commented the "Safe, closure-free..." thread, and gave some
thoughts about CSP, as mentioned I have some hard time understanding
what it does protect, there is no mechanism for setting independently
script authorities, see the example I provided and the responses I got.
For those interested I provided in the CSP thread a link to a FF bug
report where it's explained how some security policy (here Websocket
spec) forces me to do insecure things. I don't know what list can take
care of it, there is a discussion in [1] too, for now I did not see
really solid arguments showing that I could be wrong.
Maybe a solution could be combination of CSP and SES, I think SES should
come now, as far as I remember it is planned for ES8, seems too late.
Solving the code loading issue is indeed the key point, but is it feasible?
Regards,
Aymeric
[1] https://groups.google.com/forum/#!topic/mozilla.dev.security/6qBHmVAhtYY
Le 26/09/2013 10:22, David Bruant a écrit :
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
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
