Elijah Horton has a recent post to his site sharing a tool he's developed to sandbox and validate PHP code of user-contributed code.

Few quotes related to the PHP language are as pithy and resoundingly accurate as the phrase: "Eval is evil." The reasons are myriad: the eval() function basically gives whatever code is passed to it unlimited control of the parser, and this freedom makes eval() both a temptation for developers, who may need to dynamically control PHP at runtime, and a panacea for hackers who are ever-searching for more servers to add to their botnets. So, how does one make use of the extreme power available through runtime evaulation of PHP, without exposing one's server to near-certain rooting? Through a sandbox.

His tool - PHPSandbox, uses the PHP-Parser library to deconstruct the PHP code its given and look for issues. He gives an example of a call to mail and how it would catch the issue. He shows how to install it via Composer, how to configure it with whitelisted methods/functions. It also includes a way to overwrite function calls with a bit safer alternative.

The NOLOH project has officially announced the release of a large demos section of their site complete with live examples of the framework in action.

Until now one of the biggest issues with noloh.com was the need to sign-up for a free hosted sandbox, or download NOLOH in order to see it in action. No Longer. We're happy to officially announce the launch of noloh.com's Demo section. The demo section allows you to play with live demos and examples, view their source, download the complete source, and even fork your very own version on github.

Currently there's two examples for you to check out - an implementation of Hangman and an Image Broswer. Their "live example" gives a simple browser to run the application in, a source code viewer and a link to discuss the script. You can also, as they mention, fork it directly on github or just download it directly.

On the PHP 10.0 Blog, there's a new post today talking about variable tainting and what it might be like if PHP included it too.

Perl and Ruby have variable tainting. Maybe PHP should have it too?

Variable tainting is a bit of built-in functionality that provides a "safety net" of sorts to the contents of variables to help protect both the users and the script itself from potentially harmful content.

He talks about how Ruby and Perl handle the functionality and how, were PHP to work it in, which approach would fit better with PHP's current model:

If one wants to implement proper tainting or sandboxing, it probably should be based on more generic approach that would account for existence of functions unknown in design time.

On the PHP 10.0 Blog, there's a new post today talking about variable tainting and what it might be like if PHP included it too.

Perl and Ruby have variable tainting. Maybe PHP should have it too?

Variable tainting is a bit of built-in functionality that provides a "safety net" of sorts to the contents of variables to help protect both the users and the script itself from potentially harmful content.

He talks about how Ruby and Perl handle the functionality and how, were PHP to work it in, which approach would fit better with PHP's current model:

If one wants to implement proper tainting or sandboxing, it probably should be based on more generic approach that would account for existence of functions unknown in design time.