Again though, PHP apps storing configuration info in PHP is a fairly common practice. If that's the way you store that information, any typo that takes your configuration file out of "PHP mode" is going to leak data. Before today, I'm sure a lot of PHP coders didn't consider that when dealing with configuration files for applications: they chose to design that way because it's simple to deal with.
> Again though, PHP apps storing configuration info in PHP is a fairly common practice.
This isn't a problem with PHP. It's a problem with ANY app storing configuration options inside the actual language. It would be like storing vhost information in C and forcing you to recompile all of apache to get a new site up.
Yes, config options are easy to add to interpreted languages. I see it happen all the time, and not just in PHP. Perl, Python, Ruby.
The problem is that to change the config options, you are essentially changing what amounts to the application, and if you break your config, you break your application.
The standard way of storing config options in PHP is with .ini files. At least, in my circle. Sure for quick scripts, we throw it in the actual code, but whenever we have to manage more than a few config options, it get's moved out.
I realize I'm expanding on what you said a bit. =) I just want to make it clear that this isn't a PHP problem. It's a basic programming problem.
The key isn't so much that the configuration language is the source code language, but that both are a template language. As far as the parser is concerned all three are written interchangeably in an HTML superset that's sent down the wire raw by default, no matter where they're located or what called them. PHP gains its low barrier to entry partly from the fact that HTML becomes valid PHP just by changing its extension, but that useful equivalence also cuts the other way.
Many other frameworks use the source code language for configuration without risking this particular error, because they keep templates separate. (In Django, for example, templates use a different language and are read out of template-specific directories.)
It's not even a problem unique to configuration files. A disclosure of source code would have occurred by replacing the first character of a PHP source file. The fact a configuration file was involved makes the effect both more severe and less likely to be caught ahead of time. More severe, because it discloses passwords, rather than just proprietary code. Less likely to be caught, because standard testing methods tend to rely on a staging or test config instead of the production one.
There are other posts disagreeing over various single villains, but a wider view is that Tumblr was bitten by a combination of a single-character typo, an otherwise useful PHP language design choice, the common and otherwise harmless practice of configuring via a programming language, and the blind spot typical test suites have for production-specific issues.
Sure, but if they'd made just a tiny effort to test their code before releasing it they'd have caught that bug instantly. We're not talking about time-consuming tests here - we talking about loading the page in the browser once. If the PHP code is showing, you're doing it wrong.
