I'd like to know more about why having passwords stored in files with .php extensions are potentially vulnerable. Orginally, phpweblog's config file was named common.inc. The reason why this was renamed was because Apache will serve a .inc file as text/plain, blantantly exposing any precious data contained in this file. Renaming it to .php seems to be the safest way to keep this data private, as Apache will parse this file instead of display its contents. The only concern I believe at this point would be that local user on the server may be able to read this file if the permissions allow.

My thinking has been the same as Jason's too. It seems to me that the password is going to have to be stored in some sort of file, so the best would be something that doesn't have any output when someone tries to load it through apache.

I've had an eye on it, too. But never had the time to write anything about.
Wouldn't it help to create another file with the mysql connection infos in it and put that one to a safer place.
In the common.inc.php file is just the location of that mysql-connection file.
A safer place would be for example the cgi-bin directory.

I saw that configuration style for example in the nope configuration.

Can anyone agree with me ?

Huh?

Why can't you just put all include files above the web document tree - including config vars, db passwords, etc.

This makes it impossible for anyone to gain access to them via the browser.

Maybe I am missing something here?

heath - and what would those who are virtually hosted do?

I haven't been able to find out why having them in a .php* is bad, but I did read somewhere that you should change the phpscripts containing passwords so that they are not world/group readable.

So, is it possible to defeat apache serving up common.inc as text by changing it's permissions so that it's not world/group readable and thus it wouldn't serve it to a browser?

Pardon my ignorance on some of this.

It would be easy to add .inc to the files parsed by php/apache. If you have a bunch of code that's looking for .inc files and you don't want to "fix" the code.

It seems to me the safest thing to do with sensitive info would be to put it in a file that gets parsed but displays nothing.

If it's a deticated server, you could add this stuff via the prepend options in the php.ini file, Then put the file above the document root.

[quote]heath - and what would those who are virtually hosted do?[/quote]

Huh? I've never seen a virtual host that wouldn't let you go at least ONE level above the /www/ tree.

i.e.

Web directory is:
/home/yoursite/www/

Put super-secret data here:
/home/yoursite/nobody_can_see_this_dir_from_their_browser_and_is_therefore_safe_and_unless_I_am_missing_the_point_it_should_solve_the_problem/common.inc

Normally if you're virtual hosted you have a tree in which the http document tree with follow one level down.
So you either can put it in those root dir or nearly more safe in the cgi-bin directory.
The only problem are still those users having a virtual host on the same server. And as a normal user you normally can't change the group to any other group than the group you're a member from. Otherwise I'd change the rights to the group which runs the apache.