Matthew Turland came across an interesting bug when working with the Cares Document Checker he's developing related to linting (running a syntax check) on a given PHP file.

While doing a lint check on a code block, a parse error was occurring on a line that contained a comment in the original source file. [...] Presumably what was happening was, even though the var_dump() call showed that actual newlines were being interpreted correctly, the r was also being interpreted rather than taken literally. This caused the comma following it to generate the error I was receiving.

An alternative to the method he was using, shell_exec, is proc_open, a function that opens a resource to handle a command execution and allows for more than just the "point and shoot" execution that things like shell_exec, or system.

Recently on the Web Developement Blog, Olaf showed how to do a Location redirect with cURL while open_basedir is set.

If you need to follow redirects within your php code using Curl and the open_basedir is set you came into some trouble. If you disable this directive all your directories with a 777 permission are not safe (if one or more website on the same server has some security issues). If you don’t have additional protections you should NEVER disable the open_basedir directive (at least if you’re using 3rd party applications).

He writes up a simple cURL-based link checker to see which of the URLs in question would throw an error. He modifies it so that it checked the HTTP response code from the server and, if its a 200/302/301, you know things are okay and a shell_exec can be called to execute the file from that location.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.