Open nicola opened 8 years ago
Makes sense. I was thinking that a fundamental security problem is making sure that you can't do an "eval" of code that comes from untrusted input.
For example, untrusted input might include strings that come from the URL; or input that come from UI input. I sent an email on this case a second ago
Maybe this is closer to the concolic execution idea....
compared to #2 this is essentially pattern matching and nice ui that tells that there is something that could be wrong. Concolic execution doesn't check if the code contains eval
, use of fs
to read folders /../ & so on. I see though why having concolic execution would make this a better tool
I see - so this could be done as essentially a "grep" through the code.
This type of checker could also be added in the browser - maybe. This would check whether the javascript I am loading will have access from document.cookie when the website loads a library from a cdn
It is a grep + some logic for example static analysis on whether fs.readFile('/not/allowed/root') would be possible
It's not easy to make an adversary-proof version of this checker. For example suppose we want to prevent any libraries from accessing "document.cookie". If a script was adversarial, it could construct the reference saying c = "c" + "ookie" and then using document[c]... Hard to check the generic case here.
Let's talk about npm.
The spirit of Nodejs/Javascript packages is that they have to be minimal. This means that all in a sudden we end up writing a new package, with very many dependencies. Now, let's assume this dependency of packages:
Now let's assume for a second that was-useful-once contains malicious code and that my-awesome-library becomes an awesome library that everyone uses.
How does everyone checks if the code that this library is made of, is safe to run?
Problems I consider to be harmful
Possible solutions