Evert Pot has a quick post on a handy little topic - making streams from strings with PHP (see some of it in action on Davey Shafik's blog).

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.

Davey Shafik has a helpful hint for avoiding one of the worst functions to use in PHP - eval.

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.

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.

In response to this previous post from Felix Geisendorfer, Sara Golemon shares a few thoughts on why she thinks it's just the other way around - create_function is not your friend.

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

The Zend Developer Zone has posted three new helpful security tips to add to their growing list - one on mailing, one about working with privileges, and the other on the dangers of eval:

• 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.

Chris Hartjes is taking on what he calls his "next foolish project" - a console for the CakePHP framework.

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.

Harry Fuecks is back today on the SitePoint PHP Blog with part two of his "joy of regular expressions" series, continuing on from this previous entry.

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()

As you can see, it's crammed with just as much infromation as the first part and covers a wide range of topics to help you get more in tune with your inner regular expression guru.

The Daily WTF post for today bears mentioning if for nothing less than to show how to not do things. It has an interesting twist on the whole Ajax craze that's going on in the web today, and takes it to a really scary, pointless level.

The introduction of the XMLHttpRequest component (*) opened the doorway for a new breed of "fancy schmancy" web applications like Flickr, GMail, etc. This, in turn, spawned an entire sub-industry and a new series of buzzwords seemingly based on the names of household cleaning chemicals. It even incremented the current version of the Internet to 2.0.

That said, it should come as no surprise that this Borax-technology has also empowered "certain programmers" to create new perversions in information technology never imagined before. Gustavo Carvalho discovered what happens when XMLHttpRequest and the Eval() function in PHP are combined. I'll leave it to your immagination as to what the server-side looks like ...

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).