Thoughts about PHP after the Facebook Source Code Leak
Posted on August 15, 2007, under Development, How To, Networking, Security, Tools and Services, Web Hosting.
So by now, you already know that Facebook source code was leaked due to a mis configured server. And if you didn’t already know Facebook is written in PHP, a language that is compiled when it’s executed. So there are some questions that come to at least my mind about this situation.
First, what does this mean for Facebooks’ reputation? It is in a legal dispute over whether or not Mark Zuckerberg, the sites founder, stole source code from fellow university students. Even though the source code of any popular and profitable company is valuable. It is arguably not nearly as valuable as the data that goes along with that source code. This is the case with Facebook, who has millions of users and personal information in databases. But how can someone get access to the databases just by having the source code, you ask? Well with PHP it’s not so difficult. In most cases there is a configuration file that has all of the database information you need.
So how could have Facebook, and others prevent this sort of this sort of thing from happening? Here are a couple ideas:
- Put your configuration file where it can not be executed directly. For example, not in your “httpdocs” folder anywhere. In this situation Facebooks’ servers were mis configured so the PHP code was not rendering but instead showing itself. This means if the configuration file was under the “httpdocs” folder somewhere, presto! Access to the database. (Obviously firewalls and things like that might stand in the way).
- Obfuscate your PHP code. Yes this might slow down the processing of your PHP code by milliseconds, but it really would have helped in any situation like this where the possibly of PHP being show is present. Some obfuscation tools will also optimize the code, so it might make up for any processing time gained by obfuscating.
- Sandbox environments, and pulling production boxes out of rotation. Not sure what Facebook’s server setup is, but sandbox environments might have caught this server misconfiguration before it made it to production. Additionally if you have any sort of mirrored servers (a company like Facebook is bound to have something along these lines), you probably have your servers behind a load balancer. When you push code to production you need to pull these servers out of rotation (meaning not available for outside access). You can then test these servers individually before putting them back into production with the new code. Tedious? Yes, but worth it for not having a PR nightmare like your source code leaked. Additionally there are lots of tactics you can employ to make this process semi-automated and not as tedious.
These are obviously just some of many tips you can deploy to keep this from happening to you. Most large companies like Facebook will have similar processing in place, but the key is to always follow protocol… no shortcuts not matter what time crunch you are under. One slip and your source code is all over the Internet… might even be worse.
Popularity: 7% [?]


