"customer freedom over rigid rules" security wtf

So last night I was doing some work for a client's website, and noticed in their public_html directory a file named php.ini.  Seems like a rather odd place for it!  So I downloaded the file to have a look.

At the very top, a customized banner appears which looks like this (paraphrased):

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;  CrappyHostingCompany(TM) Suggests     
;;  ----
;;  If you wish to make changes to your php
;;  configuration, alter this php.ini and
;;  place it in all directories and subdirectories
;;  where you have php files.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(continued by lots of default php.ini settings)

I thought to myself, "I can understand if CrappyHostingCompany wants to grant their users the ability to customize their PHP installation.  But it seems rather unconventional to instruct the client to place the file in multiple locations within public_html."

Then I decided to satisfy my curiousity and went to http://www.clientcompany.com/php.ini -- and I was surprised and ashamed to be plainly viewing the contents of the php.ini file right there on the server.  Why aren't requests for this file denied as are all files matching "^.ht" ?
So last night I was doing some work for a client's website, and noticed in their public_html directory a file named php.ini.  Seems like a rather odd place for it!

I became excited and self-righteous and called their tech support (there's no email address on CrappyHostingCo's website, naturally) to announce this egregious security flaw.  Surprisingly, I spoke with someone who actually knew the functionality of the php.ini but admitted he didn't know much about Apache (which I didn't expect).  He encouraged me to submit a ticket using their cPanel software, so I did.

I wrote a ticket explaining all the reasons it was bad to hand over the contents of a php.ini file to any client that requested it, including the fact that the php.ini has lines in it for Verisign Payflow Pro, Ingres DB and other items.  I certainly don't even trust my graphics-designer boss to NOT put either the client's FTP or MySQL authentication information in this file, and felt this could only give malicious attackers additional information on how to exploit code on a given system/site.

I really thought I was doing the right thing.  I even provided them with the lines they could put in their httpd.conf to return a "403 Forbidden" response code for all requests for php.ini files.  I closed my email by asking them to "protect your clients from attacks, protect them from themselves".

By now you've read enough stories on this site to know how it turned out.  I got an email back this morning:

We are fully aware of the viewability of php.ini. As a company, we tend to prefer customer freedom over rigid rules, granting coding security responsibilities to the customers for obvious reasons. Most all of our customers never even touch php.ini files, or if they do, it's merely to enable ioncube or register_globals. A very small majority ever add anything sensitive to their php.ini files, and the act of doing so is generally frowned upon, especially considering the existence of the function ini_set().

You are already fully aware of proper .htaccess settings to take to block access to php.ini, feel free to implement it.

If you have any additional questions or concerns regarding this ticket, don't hesitate to reply.

Shawn
Support Level 2
CrappyHostingCo.com
866.555.5555

So, to summarize:  Most people don't touch php.ini, so this isn't a problem.  You don't have a problem either since you know how to fix it.  The emperor has no clothes!

Being a grizzled veteran (9yrs+) of web development and dealing with dozens of moronic hosting companies should have been enough to stifle any remaining idealism.  But naivete won over, and thus another small piece of me died this morning.

 [Additional rants:  register_globals and other items can be modified directly through .htaccess files.  And why in the bloody hell would someone need different php.ini settings in each of their directories to justify copying the entire file to each directory instead of using .htaccess or prepending a php file with the ini changes?]

 I would like to see this attitude in other industries as well. Take the gas company for example. What kind of nazi said those gas pipes should have such a rigid architecture?  Why don't they have an opening or two along the way, complete with valves. If I want to get gas directly from the line for my experimental flame-thrower who are they to deny me?

DOA:

I would like to see this attitude in other industries as well.

I wish Visa would publicly share their full FTP access credentials, then maybe I could afford a blow-up doll house.

Shared hosting companies are usually braindead.  Still, I wonder why the php.ini would have to be put in every directory instead of just the root.  Is it likely you're going to need separate settings for every single directory?  Ick. 

morbiuswilters:

Shared hosting companies are usually braindead.  Still, I wonder why the php.ini would have to be put in every directory instead of just the root.  Is it likely you're going to need separate settings for every single directory?  Ick. 

Heh. One job I had made me call customer support for their hosting company to ask if they had a J2EE container. I knew it would go bad, but I didn't expect for the poor sod on the phone to confuse JavaScript with Java. Ow.

 Heh, now enabling customers to enable register_globals is a hack waiting to happen...

I would generally prefer my hosting company to just give me a big box that I have full control over. If I shoot myself in the foot, so be it. I love their smartass response telling you to go implement your own .htaccess rules.

And why in the bloody hell would someone need different php.ini settings in each of their directories to justify copying the entire file to each directory

That sounds like a dumb approach, but.... do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.

do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.

Actually, I think you and I are agreeing on this one. Personally I feel it would make the most sense to permit the client to control just ONE php.ini file perhaps placed in /home/clientname. And for any directory-specific customizations, they can add ini-related directives to a directory's .htaccess file. I agree, duplication would be a bad thing, and directory-specific controls should contain ONLY the ini directives that are different from the master/global configuration.

Kozz:

do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.

 

Tip of the day: Just highlight the text in his response and press the quote button.

MasterPlanSoftware:

Kozz:

do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.

 

Tip of the day: Just highlight the text in his response and press the quote button.

 

Coming up next, the new hit series MasterPlanSoftware: Forum Police. 

bstorer:

Coming up next, the new hit series MasterPlanSoftware: Forum Police. 

 

Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.

MasterPlanSoftware:

bstorer:

Coming up next, the new hit series MasterPlanSoftware: Forum Police. 

 

Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.

 

bstorer:

Filed under: The Atlantic Ocean cannot stop curses, Relax. It's a joke.

 

Relax.  It's a joke.  I really don't have anything against you.

bstorer:

Relax.  It's a joke.  I really don't have anything against you.

 

I know. That is why I agreed with you.

MasterPlanSoftware:

bstorer:

Relax.  It's a joke.  I really don't have anything against you.

 

I know. That is why I agreed with you.

 

And I now direct both of your attention to the irony of this argu-*ahem* discussion:  I started the thread being the guy who knew what was right and told someone in an attempt to help.  I was basically told "sod off".  It's the irony of our personalities and the professions we've chosen:  to be the guy who knows his stuff... and the usual amount of ego and hubris that goes with it.  In the end, our digressions lead us far from the original topic. ;)

And I thank you, MasterPlanSoftware, for pointing out the tip.  I do actually appreciate it. :)  (long-time lurker, first-time poster, as it were) 

Kozz:

And I thank you, MasterPlanSoftware, for pointing out the tip.  I do actually appreciate it. :)  (long-time lurker, first-time poster, as it were) 

 

You are welcome. Welcome aboard.

MasterPlanSoftware:

bstorer:

Coming up next, the new hit series MasterPlanSoftware: Forum Police. 

 

Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.

 

bstorer has 5 to 10 people using his account?  Shouldn't you be doing something about that, Forum Police?

vt_mruhlin:

bstorer has 5 to 10 people using his account?  Shouldn't you be doing something about that, Forum Police?

 

Right. You are late, and you still didn't get it.

Good job.

Kozz:

And I now direct both of your attention to the irony of this argu-*ahem* discussion:  I started the thread being the guy who knew what was right and told someone in an attempt to help.  I was basically told "sod off".

 

Is that what this post was about?  I didn't actually read it, because it was long and I am lazy.  Instead, I posted a joking crack at MPS, which I now regret because some troll is probably going to come along, quote my post, and add his own slam against MPS, all the while missing that mine was a joke.

bstorer:

Instead, I posted a joking crack at MPS, which I now regret because some troll is probably going to come along, quote my post, and add his own slam against MPS, all the while missing that mine was a joke.

 

Too late, been there done that. Don't worry though, happens no matter what.

MasterPlanSoftware:

bstorer:

Instead, I posted a joking crack at MPS, which I now regret because some troll is probably going to come along, quote my post, and add his own slam against MPS, all the while missing that mine was a joke.

 

Too late, been there done that. Don't worry though, happens no matter what.

 I'll start.  MSP is a D - Bag

pig_vomit:

 I'll start.  MSP is a D - Bag

 

Excellent, you abbreviated my name, and STILL fucked it up... Three letters still too much for you?

What a retard.

Did you guys think my response wasn't a joke, or am I misinterpreting?

vt_mruhlin:

Did you guys think my response wasn't a joke, or am I misinterpreting?

 

I have no idea if it is or isn't. I used to assume people were mostly joking on this forum, but then I got corrected a dozen or so times.

Apparently, you are not joking unless you tag it as such, and state your intentions to make a joke in 36 point, bold font, in triplicate.

I know, I was surprised too.

I generally like to apply the rule that anything I say which doesn't seem to make sense if taken seriously is a joke.  It's a good general rule of thumb, but the added bonus is that it prevents me from appearing to be wrong the few times that I actually am.

I believe if you are running php as a cgi module, then all state info (session) is stored by apache and php execution is entirely stateless.  php has no concept of a public_html directory or anything, it is simply an interpreter.  So putting the file in every directory where php is executed from is the only solution other than making the changes to the main php.ini file (which is not possible on shared systems).

As for maintenance, 'find -type d -exec cp /path/to/php.ini {}\;' is not the most elegant way of handling the problem but not really a nightmare.

javaweeny:

So putting the file in every directory where php is executed from is the only solution

 

 I would contend that most users will be making only a few changes when compared with the php.ini and that for them it would be better to state those changes in their .htaccess file with multiple lines of

php_value PHP-variable value

And that's that. But then again, we're dealing with (at hosting companies) are "salt of the earth... you know, morons".

In any case, I believe the real WTF is that they would encourage this kind of usage and then NOT want to block php.ini from being served up like any other webpage.