I'm using Node.js to create the web service. In the implementation, I consumed many third party modules which are installed via npm. There is security issue if there is malicious *.js scripts in the consumed modules. For example, the malicious code may delete all my disk files, or collect the secret data in silence.

I have a couple of questions regarding this.

1. How to detect if there is security issue in the module?
2. What should I do to prevent malicious *.js scripts from executing in Node.js?

I'm very appreciate if you can share any experience to build the node.js service.

Thanks, Jeffrey

One concern you did not raise is that a module might try to make a direct connection to your database itself, or to other services on your internal network. This might be prevented by setting passwords which the module cannot find so easily.

1. Restricting disk access

This project was presented at NodeConf last year. It attempts to restrict filesystem access in precisely the situation you describe.

https://github.com/yahoo/fs-lock

"The goal for this module is to help when you are loading 3rd party modules and you need to restrict their access."

It sounds rather like the proposal Jeffrey made in the comments in Plato's answer.

(If you want to look further into hooking OS calls, this hookit project may present a few ideas. Although in its current form it only wraps the callback function, it might provide inspiration of what to hook, and how. Here is an example of it being used.)

2. Analyse flow of sensitive data

If you are only worried about data-stealing (not filesystem or database access), then you can focus your concerns:

• You should be most concerned about those packages which are being passed sensitive data. Presumably some of the data on your web-service is presented to the public anyway!

• Most packages will not have access to the full stack of your application, only the bits of data you pass them. If a package is only being passed a small amount of sensitive data, and never passed the rest of the data, it may not be able to do anything malicious with the data it receives. (For example, if you pass all your usernames to one package for processing and all your addresses to a different package, that is a much smaller concern than if you pass all your usernames, addresses and credit-card numbers to the same package!)

• Identify the sensitive data in your app, and note which functions in which modules they are passed to.

3. Perform efficient code review

You may not need to go to Github to read the code. The great majority of packages provide all their source-code in their install folder inside node_modules. (There are a few packages which provide binaries however; these are naturally harder to verify.)

If you do want to check the code yourself, there may ways to reduce the amount of work involved:

• To secure your own app, you do not need to read the entire source code of all packages in your project. You only need to review those functions which are actually called.

• You may trace the code by reading it, or with the aid of a text-based debugger, or a GUI debugger. (Of course you should look out for branching, where different inputs may cause different parts of the module to be called.)

• Set breakpoints when you call into a module which you don't trust, so you can step through the code that is called and see what it does. You may be able to conclude that only a small part of the module is used, so only that code needs to be verified.

• Whilst tracing flow should cover concerns about sensitive data at runtime, to check for file access or database access, we should also look at the initialisation code of each module which is required, and all calls (including requires) which are made from there.

4. Other measures

It might be wise to lock the version number of each package in package.json so that you don't accidentally install a new version of a package until you decide that you need to.

You may use social factors to build confidence in a package. Check the respectability of the author. Who is he, and who does he work for? Do the author and his employers have a reputation to uphold? Similarly, who uses his project? If the package is very popular, and used by industry giants, it is likely that others have already reviewed the code.

You may wish to visit github and enable notifications for all the top-level modules you are using, by "watching" the repository. This will inform you if any vulnerabilities are reported in the package in future.