About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.

All posts for Dec 2004

PHP and Apache 2 Slashdotted

Slashdot is running a story about the recent PHP and Apache 2 discussion - Is Apache 2.0 Worth the Switch for PHP?. I feel compelled to clarify (and support) Rich's main point, because it seems to be missed by quite a few people.

He believes that we shouldn't be actively discouraging people from upgrading to Apache 2. Otherwise, we should work together to fix whatever problems exist. This is mostly a reaction to the PHP documentation, which states:

Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.

To be fair, Apache 2 is more proven than PHP 5, but there doesn't seem to be the same level of discouragement for upgrading to PHP 5. In short, I think Rich has a point. Let people decide for themselves whether something is stable enough for their needs. Opinions expressed in the PHP documentation seem more authoritative than suggestive.

This has nothing to do with whether there is a compelling reason to upgrade to Apache 2 or whether PHP can guarantee thread safety - the question being raised is whether there is a compelling reason not to use Apache 2 with PHP, and if there is, what is it?

I personally think Rich has nothing but good intentions and wants to see PHP and Apache 2 working as well together as PHP and Apache always have.

More information:

PHP and Apache 2

Rich Bowen, a notable member of the Apache community, has commented on PHP's anti-Apache2 FUD. He makes some good points, such as the fact that there's more to Apache 2 than threading.

Rich and I spoke about this issue at ApacheCon. During our brief conversation, I tried to convey my perception of the PHP community's opinion:

  • The main reason to move to Apache 2 is threading.
  • Due to various factors, we cannot guarantee thread safety in every PHP installation.
  • Apache 1's architecture is proven and reliable.

Rich immediately interjected after my first point, pointing out that Apache 2 had much more to offer than threading. Having very little experience with Apache 2 myself, this piqued my curiosity.

Was my perception of the PHP community's opinion wrong, or is this how most of you feel? What are your remaining concerns when PHP is running under Apache 2 (Prefork MPM)?

PHP Security Announcements

I've been asked about the "security issues" that prompted the release of PHP versions 4.3.0 and 5.0.3 enough times to warrant blogging about it. I understand the concern - you visit php.net and see:

The PHP Development Team would like to announce the immediate release of PHP 4.3.10 and PHP 5.0.3. These are maintenance releases that in addition to non-critical bug fixes address several very serious security issues.

Very serious security issues? That sounds "very serious." You read the PHP 5 ChangeLog (or maybe the PHP 4 one) and see a big list of changes. At most, you can identify two changes that might be security fixes:

  • Fixed potential problems with unserializing invalid serialize data.
  • Fixed a bug in addslashes() handling of the '\0' character.

Luckily, better information is available:

Update: Ilia points out the 4.3.10 release notes, which have more information.

Character Type Functions

An oft-overlooked PHP extension is ctype - a collection of functions that can help you determine whether a string belongs to a particular character class, such as alphanumeric. This extension is built-in as of PHP 4.3.0, so you may not have to do anything special before you can start using it.

The ctype functions are particularly useful for handling $_GET and $_POST data - elements in these superglobal arrays are always strings, and because they are sent by the client, you must treat them with suspicion.

Security-conscious PHP developers frequently use regular expressions to filter external data. While this is still the best approach in many cases, there are a few common character classes that are easier to filter with ctype functions:

A nice side-effect of using ctype functions is that they take locale into account. For example, I consider alphabetic characters to be [A-Za-z], but this isn't true everywhere. In fact, many common European names have characters that are not accounted for in my simplistic pattern.

Here is an example using ctype_alnum() that tests whether $_POST['username'] is alphanumeric:

= array();

if (
$clean['username'] = $_POST['username'];
/* Error */

There are plenty of cases where a regular expression is still best, but I think the ctype functions are worth a look.

Holiday Greeting


Free Security Corners and a Guru Speak

There are three new articles available at http://shiflett.org/articles:

I hope you enjoy them.

PHP Security Consortium

A little over a month ago, I mentioned the PHP security experiments that I've been conducting. I also solicited volunteers to help with my research.

Many gracious PHP experts from around the world have offered their aid. I did not expect such a response (nor all of the attention that this has received), but I appreciate everyone's interest. I want to keep this group small, and I want to make sure that I only involve people with high ethical standards, so I have chosen a handful of people that I know - either personally or by reputation (through their involvement with and/or contributions to the PHP community). This doesn't mean that I don't trust the others, and it's very likely that more people will have a chance to be involved later, because it looks like this may turn into something much more than a research group.

In addition to myself, the following people are volunteering their time to help promote sound security practices within the PHP community:

Because Ben is proposing a talk to be given at PHP Quebec that discusses our research, discoveries, and progress, we have chosen a name for the group - the PHP Security Consortium. We're still just a small group of people conducting some research, but now Ben has something to call us in his proposal.

In addition to conducting research, we have plans to provide several PEAR modules, improve a few others, generate plenty of documentation, and speak at user groups and conferences - all with the intention of educating the PHP community about security concerns (both old and new) and providing tools and best practices to help promote secure application development.

Testing PHP

I guess this is my belated ApacheCon blog. I had a lot of fun as usual, and I got a chance to meet a few new people and hang out with old friends. The talk that Geoff and I gave went really well, and it ended up being as funny as we had hoped. More exciting than the talk is the project behind it. I think we've created a really nice testing framework for PHP applications, and I'm going to try to describe it for those who missed the talk.

There are a couple of resources available for download:

What's so great? Apache-Test - a testing framework for Apache that adheres closely to strict testing ideologies. Geoff and I have added features to Apache-Test that let you use it to test PHP applications. In addition, we have provided a PHP implementation of Test::More - a popular CPAN module that has some very simple functions that make writing tests easy.

The idea for this project began at OSCON, where Geoff and I were discussing testing tools and methodologies. The Perl community has embraced testing as a key component of a developer's skillset, whereas the PHP community still relies heavily upon echo and manual testing with a browser. Since Geoff is a Perl guy, I'm a PHP guy, and we happen to be good friends, we decided to create a way to let PHP developers benefit from Perl's mature testing tools and methodologies. Since Geoff is really a mod_perl guy and interested in all things Apache, he is a big fan of the Apache-Test framework. This seemed like a great tool to provide to PHP developers, so we proposed a talk about it. Once the talk was accepted, we had to deliver.

What makes Apache-Test so great for PHP developers? It provides several key features not available (to my knowledge) with any other testing framework:

  • You don't have to write any Perl. This certainly isn't a unique feature, but one problem with our attempt at being funny in the naming of the talk is that people tend to think that using this framework requires you to know Perl, and that's just not true.
  • You don't have to write any tests in your application. One thing that bugs me about several of the testing approaches I have seen is the necessity of including tests within the application itself. Thus, your tests can affect the behavior of your application, which totally ruins the concept of testing. You see, testing an application should be an example of a control experiment, where there is only one thing that changes - your application. If all tests pass, you make changes to your application, then some tests fail, you want to be assured that the cause of the problem is the changes you made to your application, not tests that you have written. In fact, a test shouldn't even affect any of the other tests, much less the actual application you're testing. I think this flaw in existing approaches has stymied our adoption of testing as a necessary skill.
  • Writing tests is easy. I think this is a key feature. If writing tests is a hassle, no one will want to do it. Let's be honest - developers are lazy. In fact, we take pride in being lazy. The PHP implementation of Test::More that is now included in Apache-Test provides simple functions for writing tests. You can use these with any programming paradigm, which means you don't have to use an object-oriented design, but you can if you want.
  • The tests are repeatable. This means that you can repeat your entire test suite as many times as you want, and running the tests doesn't affect the environment (or future iterations of the same tests) in any way.
  • The tests are automatic. You don't have to manually browse your application or execute tests. You just type make test, and Apache-Test takes care of everything else.
  • You get a self-contained and pristine Apache environment. Not including tests in your code isn't enough - you want to have as much consistency in your environment as possible. Apache-Test gives you a separate Apache environment with its own configuration (including a pristine httpd.conf and php.ini) using your build. You augment the default configuration in a separate file, so that every change must be deliberate (it is also a good practice to keep your changes to the real Apache and PHP in a separate file, so that you can be sure that it has the exact same configuration as your testing environment). When you type make test, Apache-Test starts the server, runs your test suite, generates a report, and stops the server.
  • Your application is executed with the real PHP. You can now also choose to run tests with the command line client.
  • It's very mature and stable. Major companies and open source projects have been using Apache-Test for years. It's a proven tool.

These are the major features (that I can think of) that I find particularly appealing. I'm sure there are others. Perhaps a nice side-effect is the potential for cross-pollination between the Perl and PHP communities.

If you're interested in learning more, please download the demo and the slides from our talk. To run the demo, you'll need Apache-Test 1.16 or greater. You can find the most recent version from search.cpan.org.

This testing framework is only available for Apache.