In many of the applications I write, one of my first considerations is how to make it extensible by others. This approach has several advantages - for me, it's a method of setting a boundary around the core functionality of the application, knowing that I may not get around to implementing every feature that a user might want, but that I've left them the ability to extend it should they choose to. This approach is widely used, especially in the JavaScript ecosystem where tools such as Grunt or Gulp have the vast majority of their functionality in plugins rather than the core. Similarly, content management systems also commonly use a plugin architecture.When building these types of systems, one of the most significant challenges is providing this extensibility while simultaneously ensuring that the untrusted code in those 3rd party plugins does not become a wide open back door that compromises the security of the system. While this can be difficult to impossible in many languages, Node is somewhat unique in that there's not much you can do without requiring a module and, in Node, the behavior of that module loader is entirely customizable. By limiting the untrusted code's ability to load sensitive modules (like 'fs'), the risk it poses can be significantly reduced.To that end, I built Module Cop as a tool for creating secure sandboxes - I'd be interested as to whether this is even a problem that many others face. Also, while it locks down module loading, I'd be interested in what other vectors might need to be addressed to make it fully safe to execute untrusted code.https://ift.tt/2UahzPj
Submitted December 05, 2018 at 05:18AM by AmericanBlarney
No comments:
Post a Comment