PHP

We’ve all seen Apache serve up some source code when it should have been parsing PHP, or whatever you’re server side language of choice is, but what can we do to prevent it?

Although it seems improbable I have seen a case where this could be attributed to achieving a mysteriously unstable Apache or PHP state. This particular server happened to be mis-configured to load APC as a shared object even though it was already compiled into PHP statically. I recently tried to reproduce this but failed when running a recent build of APC. I do know, however, that removing the erroneous apc.so solved the problem.

We, at Facebook, recently encountered a similar issue resulting in the same outcome. It was the middle of August when I got a message from a user wondering why we were showing him ‘codes’ instead of search results when he was searching for a friend. He was able to reach me because my email address is in the first 10 lines of the source code for s.php. This source code was visible to him rather than the search results he was looking for so I dropped everything to try and figure out why.

This shouldn’t have been possible running the Apache modifications we have in place. We had already patched Apache to detect requested PHP extensions that return a non-handled response, preventing source code from being returned. Although similar results can be achieved using an Apache module such as mod_security, this module only supports output filtering in Apache 2. We decided to patch Apache 1.3 directly which has the added benefit of averting a potential configuration error. This patch for Apache 1.3.37/1.3.39 is now available here.

After looking at every possible angle, I was unable to configure our Apache build to serve source code even if we wanted to. What we eventually found was a single server running a standard distribution build of Apache in our production pool of several thousand web severs. A lot has been posted online blaming PHP for this, however, the server that we eventually found was not running PHP. In order to criticize PHP we should scrutinize the implementation details of the language itself and eschew the attributes that are common among all web server programming languages.

These sorts of issues can and do happen to anyone, large or small, so what can you do to minimize the damage when this situation arises? As I mentioned earlier, you can use a module like mod_security and it’s response parsing features, however this does not come free of cost. You’ll need to be running Apache 2.x and if you are concerned with PHP performance this is not a good choice today, see Ilia Alshanetsky’s article Apache 1 vs Apache 2 Performance. If you’re already running Apache 1.x you can take a look at our patch but you can also do more, like abstract all PHP pages by implementing an include which evaluates code outside of the document root:

/siteroot/docroot/index.php:
include_once '/siteroot/site/index.php'; // point to the real index.php
?>

Although not absolutely preventing source code leaks, this method, proposed in the blog New Web Order, is sound advice and minimizes risk when an exposure occurs. In an optimized APC environment, where apc.stat=0, this added abstraction should come at little to no cost in performance.

Simple problems such as this can affect anyone large or small and as the complexity of an environment increases it requires more robust auditing and monitoring. Open source monitoring toolkits largely lack the necessary features to scale in support of these environments so it is essential that we continue to build and improve these systems internally to prevent and detect problems like this. If you are interested in building these types of systems with us or working on PHP with us, feel free to contact me or checkout Facebook Jobs.