In a new post to their blog, Exakat looks at the use of eval in PHP applications and how, despite all of the warnings against using it, it's still found in quite a few codebases (based on their scans).

It is 2018, and we can still find eval() being used in more than 28% of every PHP code source. It is repeatedly reported as a security issue and a performance bottleneck, and a memory hazard. Yet, we can’t get rid of it.

It seems reasonable to think that most of eval capabilities are available as a PHP features. So, we took examples from 2000 PHP open source projects, and reviewed the situation. Here are real-life examples of eval usage : for each of them, we’ll discuss the actual replacement.

Their examples include the use of eval for:

• JSON decode replacement
• Creating missing classes
• Rewriting classes on the fly
• Code compatibility
• Dynamic variabling

...and several more. Each comes with a summary of the method and code showing how it's being used. While some of the suggested replacements are built-in features of the language, others are recommended packages that can provide the same or similar functionality to what the original author was trying to accomplish.

On the SitePoint PHP blog Christopher Pitt is back with another interesting article, this time talking about two "delicious evils of PHP" - the eval and exec functionality.

I want to look at two PHP functions: eval and exec. They’re so often thrown under the sensible-developers-never-use-these bus that I sometimes wonder how many awesome applications we miss out on.

Like every other function in the standard library, these have their uses. They can be abused. Their danger lies in the amount of flexibility and power they offer even the most novice of developers. Let me show you some of the ways I’ve seen these used, and then we can talk about safety precautions and moderation.

He then talks about some of the "interesting" things you can do with these two pieces of functionality including:

• Dynamic Class Creation
• [Creating] Domain Specific Languages
• Parallelism (with exec)

He ends the post with some advice how to avoid issues with the topics he's mentioned and how to "stay safe" while still using these two dangerous pieces of functionality.

In a new post to his site Mark Baker take a look at anonymous classes, a new feature in PHP 7, and a challenge he took on to figure out how to apply traits to them at runtime.

One of the more interesting new features introduced to PHP with the arrival of version 7 is Anonymous Classes. [...] Then back in January (as I was waiting for my flight to the continent for PHPBenelux) I was intrigued by a request to find a way of dynamically applying Traits to a class at run-time. With time on my hands as I was sitting in the airport, I considered the problem.

His first idea was to build an anonymous class, extending the requested class that would come along with the traits/properties/functionality of the original class. He includes some of the code he tried to implement this solution and ultimately figured out that a factory would be a good approach to creating the structure. After doing some research he found a way to create the factory using some eval magic. However, this wasn't "the end of the story" as he found out some other interesting things about anonymous classes (such as the fact that they're linked to only one instance of a class, making them less reusable).

Anna Filina has posted a quick hint around testing methods that make static methods calls to other parts of your application. Static method calls are notoriously difficult to test, especially with PHPUnit.

I had trouble testing a particularly painful codebase. It had static calls and implicit dependencies all over the place, to name just a few problems.

One of the things that it often did was to call static methods that would increment counters in the database and cache stuff. Example: Record::incrementViews() It was making things difficult. To avoid messing with the original codebase too much, I came up with this quick and dirty way to ignore those dependencies.

Her solution makes use of a mockStaticDependency method that then turns around and redefines the class in question (like her "Record" above) with a __callStatic through an eval. She points out that usually using eval is "evil" but in this case it made testing the functionality much simpler when no feedback was needed from the static method. In the comments on the post, someone also makes a recommendation of the Patchwork library for PHP that allows for "monkey patching" and modifying classes/functionality to redefine functions and methods in a similar way.

In his latest post Anthony Ferarra makes a suggestion about teaching developers how to solve problems via a "quick fix" versus educating them about the real problem: educate, don't mediate.

Recently, there has been a spout of attention about how to deal with eval(base64_decode("blah")); style attacks. A number of posts about "The Dreaded eval(base64_decode()) - And how to protect your site and visitors" have appeared lately. They have been suggesting how to mitigate the attacks. This is downright bad. The problem is that these posts have been suggesting things like "Disable eval()" and "Disable base64_decode()" as possible solutions. And while technically that would work, it completely misses the point, and does nothing to protect users

He suggests that developers shouldn't just look for a "quick fix" solution posted in a tutorial somewhere and go on their merry way. One danger in this is that those instructions could only be patching part of the problem, not all of it. In this case, the disable eval/base64 handling is only a code-level fix. If this exploit exists in your application, the attacker was able to get to the local file system - a much bigger problem.

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.