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:
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)?
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.
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:
<?php
$clean = array();
if (ctype_alnum($_POST['username']))
{
$clean['username'] = $_POST['username'];
}
else
{
/* Error */
}
?>
There are plenty of cases where a regular expression is still best, but I think the ctype
functions are worth a look.
s/ss/s
There are three new articles available at http://shiflett.org/articles:
I hope you enjoy them.
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.
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.
del.icio.us
Digg
Reddit
Newsvine
