Plugins are a big deal (see http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a recent example.) In this era of mashups and breakneck innovation, developers must rely on vast amounts of code they've never seen, let alone audited. Wordpress, Drupal, and many other tools developed in PHP make plugin development easy and extremely powerful. While these tools constantly work to improve security (and, at least relatively, do a solid job most of the time), there remains significant challenges due to globally accessible functions that allow manipulation of the environment (files, DB's, networking, etc.) Any plugin can use these global functions to work around the security restrictions imposed by the framework, library, or CMS.
While code audits can locate the offending scripts, this is a challenging task, both in terms of time AND abilities. Languages and/or environments that can mitigate these issues for the developer, while far from fool proof, do offer real value on the security front. Lua provides the ability for developers to limit the functions available in the current environment: http://lua-users.org/wiki/SandBoxes PHP does have an extension that offers several forms of sandboxing: runkit. However, it's often not available in shared host environments. The include (and require) construct is the front door for any plugin code. What if PHP offered functions that implemented sandboxed versions of the include and require language constructs (e.g., included_restricted('file/path', $functions = array('file', 'file_get_contents')))? Functional specs could include: 1) Internal functions seen as universally safe would by default be allowed (e.g, str_replace(), array_pop(), etc.) 2) Unsafe internal functions would have to be explicitly declared (e.g., file(), stream_*, etc.) 3) Any includes or requires within the sandboxed code would be forced to meet the same restrictions. (tricky) 4) Code containing unsafe functions not included in the whitelist would raise an error. There would be a performance hit for code that actually used the sandboxed functions to include scripts, but for many applications, I suspect this would be worth the hit. Security is becoming more important by the day (just ask github: http://homakov.blogspot.com/2012/03/how-to.html#), and empowering the developer with tools to enforce greater restrictions on the ever-growing heaps of unaudited code seems wise. Thoughts? Adam
