ES Native Mode proposal
vitteaymeric at gmail.com
Thu Sep 26 02:11:40 PDT 2013
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  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?
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
> 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
> 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.
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss