On PHPMaster.com today Shameer C has a new tutorial introducing you to Boris, a REPL (read-eval-print loop tool) that's a bit more enhanced than the basic PHP interactive shell.

As web developers, we know the importance of the JavaScript console provided by the browser in testing out code snippets. We don't need to write an entire HTML page and JavaScript code just to verify the functioning or logic of a small routine we wrote. Instead, we simply run the expressions in the console and immediately see the results. Similarly, a REPL (Read-Eval-Print Loop) is the console of a programming language in which we can write code line-by-line and see what it does. [...] PHP's REPL is very good in what it does, although it does have some limitations. [...] And so, Boris tries to solve these problems and other concerns as well.

He walks you through the installation (via a git clone and, later, through Composer) and shows how to run it as well as some sample output. He also shows how to make a custom command-line Boris runner and how to embed it into your application. His example of a tool that would benefit from this is a command-line web service client using Boris and Guzzle.

As Ars Technica reports, there was a recent exploit found on the SourceForce website's installation of phpMyAdmin that allowed an attacker to POST anything to the site to be executed.

Developers of phpMyAdmin warned users they may be running a malicious version of the open-source software package after discovering backdoor code was snuck into a package being distributed over the widely used SourceForge repository. The backdoor contains code that allows remote attackers to take control of the underlying server running the modified phpMyAdmin, which is a Web-based tool for managing MySQL databases. The PHP script is found in a file named server_sync.php, and it reads PHP code embedded in standard POST Web requests and then executes it. T

The backdoor was somehow snuck into the code of phpMyAdmin on one of the mirrors and distributed to those downloading version 3.5.2.2. They think that the only downloads that were tainted with this issue were on the "cdnetworks" mirror site. You can find out more about the issue in this advisory - be sure you check your installation for a "server_sync.php" file and remove it if it exists.

In this new post Gonzalo Ayuso talks about "using eval without using eval" in PHP applications - executing PHP code without having to use the eval function to do it.

Yes I know. Eval() is evil. If our answer is to use eval() function, we are probably asking the wrong question. When we see an eval() function all our coding smell's red lights start flashing inside our mind. Definitely it's a bad practice. But last week I was thinking about it. How can I eval raw PHP code without using the eval function, and I will show you my outcomes.

He includes some sample code showing a basic script with a class and a loop executing normally, then an "eval version" that puts it all in a string and executes it. He offers a different method - not an ideal one since it requires being able to write to the local file system, but prevents the need for eval - writing the PHP code to a temporary file and using a "fake eval" to pull it in.

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.