There are situations where a string instead needs to be used, and for these purposes the data: stream wrapper is used. Initially I thought it was only possible to encode the actual string in base64, which I didn't like because of the added footprint. [...] Quickly checking out the rfc, it turns out that ';base64' can be omitted to just pass along the raw data, which makes a lot more sense in the context of PHP.

His example takes in an example string and pushes it back out the other side after base64 encoding and decoding it. Davey Shafik found a use for it in avoiding an eval call.

There are a shed-load of ways to "eval()" code without actually calling the eval() function '" usually done simply to avoid the use of the dreaded "evil()" function, but often times because the system has eval() disabled using "disable_functions" in php.ini. Here is another simple way to avoid eval() without writing out files to the filesystem

His example uses the streams wrapper to natively execute the code from a string variable as a data element, base64 decoded. It's more of a proof-of-concept than anything else, but its an interesting solution to a tough problem to solve at times.

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.

In the short post she lists just a few of the issues surrounding the use of the function including that it:

• is prone to critical abuse by user-supplied code
• skips opcode cache optimizations
• encourages not using comments (evil)
• 100% blind to reflection or PHPDoc style documentation generation

• In tip #10, Cal looks briefly at some of the dangers of blindly using form input when sending a mail. One never knows what kind of nasty headers a user might enter.
• Tip #11 recommends the "path of least privileges" when it comes to allowing access to your application. Don't go global when simple will do just fine - even with the best of intentions, the wrong access can lead to big issues.
• Finally, in tip #12, one of the more discouraged functions in PHP is discussed - eval. This one little function, when fed the wrong kind of string, can unravel your application from the inside out and provide a would-be attacker just the opening they might need.

You can check out more great security tips like these on the Zend Developer Zone website.

On the CakePHP mailing list, somebody familiar with Ruby on Rails' console functionality asked "why isn't there one of these in Cake?" [...] So I got to thinking about how to do this. On the surface, it seems the easiest way to do this is to write a PHP script that takes entries on the command line, run the input through an 'eval' statement. Sounds easy enough, and I could write that in a hurry. I think the trickiness comes in figuring out how to hook it into CakePHP so that you can access Models that already exist.

For those attending the Vancouver PHP Conference, attend his talk and you might get amention of how far he's come with the idea. Otherwise, stay tuned to his blog for updates.

He jumps right in, summarizing the first part in a small section before getting back into the examples:

• Hunting for .jp(e)gs
• Escaping Meta-Characters
• Search and Replace
• preg_quote()
• preg_replace()
• Word Boundaries, Word Characters...and everything else
• Sub patterns
• Spot the XSS Hole
• eval() is evil!
• preg_replace_callback()

You should definitely check out the code on this one - using evil() is bad enough, but passing code back to the PHP server like that is just wrong (and a huge security hole).