前阵，比特股的创始人Daniel Larimer质疑lisk系统存在的一系列问题，虽然绝大多数问题都被lisk的创始人之一Max正面回应过了（具体可以看看这个），但还是有一个问题，Max没有回应或者说还没有提出解决方案。
那就是lisk侧链的运行环境，Larimer说
“Lisk所面临的大多数问题，都可以通过一个高度定制的JavaScript 环境来解决。”
否则，lisk的系统面临两大考验：
首先，也是最重要的，lisk目前的沙箱机制不足以限制侧链代码的权限，也就是说无法运行不受信任的代码，那些代码可能会盗取服务器的关键信息，或者直接对服务器进行破坏 。
其次，是关于侧链开发者的，lisk的侧链代码是运行在一个拥有全部能力的javascript环境，这里面有些可以导致不确定因素的函数，比如 Math.random，lisk官方的开发文档特别指出希望开发者避开这些函数，这对开发者会造成心智负担，如果是一个定制版的javascript环 境呢，直接把那些导致不确定因素的函数干掉，开发者根本不需要花费额外的精力去避开那些陷阱。
我们先说为什么要用沙箱。沙箱(sandbox)是云计算平台广泛采用的安全防范措施，是一种访问控制机制，其目的是为了限制应用代码的权限，防止 应用代码对系统进行随意的访问和破坏，因为在云计算平台中，应用代码是由各种各样的第三方开发者实现的，他们的代码是不能被信任的，需要沙箱来做一层隔 离，让这些应用代码只能做有限的事情。
lisk在区块链领域是很类似于云计算平台的，他们提供一些服务，允许第三方开发者基于这些服务构建他们自己的应用程序(即dapps)。
所以lisk也需要沙箱机制来保证dapps的作者无法作恶，lisk的做法是提供一个定制版的nodejs环境来达到这一目的。
具体实现在这段代码里，https://github.com/LiskHQ/lisk-node/blob/v0.12.14-lisk/src/node_sandbox.cc
我经过分析，发现这个sandbox名不副实，只是使用管道手段实现了进程间通讯，而且是使用一种绕弯的方式实现的。nodejs的进程间通讯可以通过javascript代码直接实现，为什么要用c++来实现呢？
我带着这个疑问，和一些期望，亲手做了一个实验。
我首先使用lisk-cli创建一个hello world侧链
lisk-cli dapp -a
接着我在侧链程序的入口处dapps/<dappid>/index.js, 加了一段代码
console.log(require("fs").readFileSync("../../config.json"))
然后运行之，于是我得到了这个服务器主节点的受托人的所有密码
"forging": {"secret": ["wKyoJM1vS4ucHmWvxDSdcpC23mJwqfg3G6MKZoXaFfcnWHTqo7","2aTWYPpQidVunxTg3y8YESYps7za6f9d4wYn9Gy2GuGnE7JX7V","65uZNjL36Bdg2tkJnueYkd2n6YPe76fpdeYtgu7fso1m385mwD",
…………
果然，这个沙箱并没有起隔离的作用，拥有管理员的权限，这等于给黑客敞开了大门。
有人说，lisk系统设置了二级密码，你获取了他的一级密码，还是没法盗取他们的钱。
也有人说，可以通过linux自身的权限机制，给侧链代码一个低级用户，使之无法访问其他用户的文件。
这些都是治标不治本的办法，根本解决途径是按照lisk预先设想的那样，要让沙箱名副其实，做到真正的环境隔离，要让侧链代码对外界一无所知。
那么，如何实现真正的沙箱呢？有很多种方案，比如跳过nodejs，直接使用v8引擎，或者使用进程级别的权限控制，比如windows系统的
SetWindowsHookEx，当然，lisk目前并不打算支持windows版本的完整版钱包，那么在linux系统中可以使用seccomp技
术。
我这里有种更简单的方法，那就是利用nodejs自带的vm模块。
var vm = require('vm');
var context = vm.createContext();
vm.runInContext(sideChainCode, context);
这几行代码完成了对侧链代码的隔离，sideChainCode中只能进行纯粹的运算逻辑，只能使用少量的v8引擎内置的javascript标准库。甚至连setTimeout，console.log都没有。
我们需要做些额外的工作。
比如，给运行环境添加setTimeout和clearTimeout
context.setTimeout= function(fn, delay) {
if (typeof(fn) == 'string') {
setTimeout(new Function(fn), delay)
} else {
setTimeout(fn, delay)
}
};
context.clearTimeout = clearTimeout;
添加日志打印功能，让侧链的日志，转发到主系统的中
global.print = send.bind(global, 'stdout');
global.console = { log: send.bind(global, 'stdout') };
global.process = {
stdout: { write: send.bind(global, 'stdout') }
};
global.postMessage = send.bind(global, 'message');
另外，还可以禁用那些导致不确定因素的函数
global.Math.random = undefined;
这些都做完以后，侧链代码的访问权限就被限制在一个狭小的范围内了。它们无法使用require，fs，http等nodejs内置的标准库。
这样安全的目的达到了，但是引发另一个问题，那就是功能性的问题了，不能使用那些额外的库，只有js的标准库也太不方便了，很多复杂功能无法实现，特别是没有了require之后，连模块化都做不到了。
所以我们需要第二步。
webpack本来是一个前端常用的打包方案，用于模块化的管理前端项目。很多人忽略了其实在后端webpack同样适用，并且可以把node_modules里的库，甚至nodejs的一部分内置库一起打包。
也就是说前端能用的js库，除了UI相关的之外，在侧链沙箱内，也都可以用，比如async，bytebuffer，crypto，js-nacl，bignum等等，这对于侧链来说够用了。
那些不能用的库，比如文件系统、多进程、网络模块，正是我们想要抛弃的。
vm + webpack的组合堪称完美。
这是日新月异的前端技术带给javascript这门语言的福利，也是以太坊的solidity等新语言望尘莫及的。
不过我们还需要一些收尾的工作
目前侧链代码中有些地方使用了一些比较复杂的库，比如ed2curve，涉及到非常多的依赖，我们认为是没有必要的，这部分功能可以在主链中提供，通过进程间通讯以api的方式提供给侧链使用。
这样也可以减轻侧链代码的累赘，还可以让侧链开发者更加轻松。这些代码对整个框架的影响非常小，可以忽略不计，但是它们依赖的库却占用了一半以上的代码量，其中还包括了沙箱环境不允许的一些操作。
经过分析，我发现只需要禁用modules/api/crypto.js中的两个函数即可
Crypto.prototype.encrypt
Crypto.prototype.decrypt
另外，js-nacl这个库里依赖了fs模块，但是相关函数并没有被用到，暂时通过手工修改的方式，把fs相关代码去掉就可以正常打包并运行了。
最后，我把一个完整的侧链项目和主链框架中的关键代码打包放在这里了。http://o7dyh3w0x.bkt.clouddn.com/asch-sandbox-solution.tar.gz
希望能给lisk的开发团队一个参考，在他们开放注册侧链应用之前，把漏洞修复。
声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。
