secure-require / secure-require Goto Github PK

View Code? Open in Web Editor NEW

54.0 4.0 3.0 694 KB

A secure require implementation for ECMAScript

License: MIT License

TypeScript 84.91% JavaScript 15.09%

nodejs modules commonjs

secure-require's Introduction

secure-require

A secure require implementation for ECMAScript

Feel more confident running a bunch of untrusted dependencies as a part of your application or module by allowing said dependency to only use a subset of core APIs. This allows you to make sure that none of the sub-dependencies try anything unexpected, or are able to alter the global objects of your own application code, no matter which version you upgrade to.

Notice

I'd like to humbly request you to please refrain from using this module anyplace critical since it hasn't been audited properly and is still undergoing massive changes. You should be able to better rely on it once the v1.x is released.

Security Model

Full global isolation: Each top-level dependency is run in a separate container.
Safely restrict the require tree to only a subset of allowed modules, including restricting Node.js core access.

Features

Zero dependencies (wouldn't that be ironic).
Uses the same stuff require uses behind-the-scenes, so performance dip should be next to none.
Supports core, third party and local modules.
Cache modules in the same context so that you get close to the speed of the original require function without losing any of the security guarantees.

Imposed Restrictions (Incompatibilities)

The following are the security restrictions that are imposed by the function on your dependencies to ensure your safety. In case you disagree with any of these, or have a valid use case for doing any of the following that you believe should be supported, please do not hesitate to reach out.

A dependency cannot make use of any core module which isn't whitelisted throughout it's subtree (duh).
Since modules are compiled in seperate VM Contexts, monkey-patching globals will not work.
When a module requires a core module, they cannot set any property anywhere on that core module.
The use of module.require is forbidden.
No module can require the Module class anywhere down the chain.

Installation

npm i secure-require

Usage

const secureRequire = require('secure-require');
// Since secure-require doesn't have any dependencies, this should be fine.
secureRequire('acorn', []);
// This should pass since acorn is written without any dependencies or core modules.
secureRequire('base', []);
// This should fail since base requires the util core module.
secureRequire('base', ['util']);
// This should pass since we just allowed base to use the util module. Now, we
// need not worry about base doing anything funny with the filesystem or the
// network. It literally cannot.

License

MIT

secure-require's People

Contributors

Stargazers

Watchers

Forkers

guybedford hitsthings fabiosantoscode

secure-require's Issues

Avoid repetition of whitelisted modules

First of all - great idea! I can definitely see myself integrating something like this in my codebases.

But this got me thinking about modules that are required across many files (e.g. something like request). It's going to be unmanageable repeating secureRequire("awesomeModule", ["dep1", "dep2", ...]) all over the code.

Obvious solution that comes to mind is having a configuration file that will hold whitelists:

{
  "awesomeModule": ["dep1", "dep2", ...]
}

so you can just go with secureRequire("awesomeModule").

I know this might sound like a stretch, but it the future this might even part of package.json as a vital part of your module's definition:

package.json

{
...
  "dependencies": [...],
  "security": {
    "awesomeModule": ["dep1", "dep2", ...]
  }
...
}

Or maybe you already have a solution in your mind that addresses this problem?

Potential holes

This is an awesome idea and I'm keen to try it out!

Was looking at the source and thinking about potential holes worth looking at. You've probably thought of them but I figured it couldn't hurt to help:

fs can be used in conjunction with eval/vm to run code, perhaps including core modules. Is there a way to avoid the fs module being a Game Over?
do WebAssembly modules open any holes?
your source already has a note about native modules.
can any core modules be found by requiring other core modules and navigating prototype chains?
can the prototype chain of the require function you pass in be navigated to access anything?
Can I access core modules via the debugger port if the app is run with --inspect and 'net' is permitted?
child_process obviously exposes everything since you can just run node again.

I'm happy to investigate any that you haven't yet, if you're looking for help.

Cheers!

Compiled dependencies

Hey there!

What is the plan for secure-require and compiled dependencies?

If someone ships a module written in C++ to npm (without requiring any node core dependencies), couldn't that someone escape the sandbox? Or at least write anything to the filesystem using POSIX APIs, open TCP sockets etc from C++?

For example, let's suppose you use Terser with secure-require on your server, but a bad actor has gained publish rights to one of Terser's dependencies (or Terser itself). Wouldn't they be able to add C++ code to this dependency that then runs natively and freely on your machine?