I run a popular PHP application that keeps the mySQL database username and password in a config file, read in by the PHP programs.

Running this on a shared server, I have some security problems.

Apache runs as nobody, so the files need to be w=r. Anyone else on the server can read my mySQL username and password information.

I found an article on the web that suggested setting the php variable open_basedir in Apache to my home directory - and of course to do this in all the virtualhost entries of the config file.

I'll talk with my hosting company to make this change; however I don't have confidence they will do so based on prior technical support experiences. Do any of you automatically set this in your Apache config files on servers you manage?

The w=r problem is harder to solve on my server. The suggestion in the prior mentioned article was to set all the user accounts in the same group in the server, and make sure that the web server runs in a different group. Setting the protections on the files to 604 will then allow the web server process to read the files, but not any other users on the box.

The accounts on my server are all in unique groups. This precludes the 604 protection trick. Are there any hosts out there that actually do this? Is it adaquate to keep people on a shared server from reading my files?

Any other ideas? How about a way to effectively read in the password in an encrypted form then decrypt it in the PHP application to use it? This would have to be done in a manner that would be hard to reverse engineer with the PHP source code, but... I was thinking about a binary distributed withe the application that did the encryption/decryption with a reversable algorythm that was not part of the PHP code...

Any ideas?

Thanks,

-t

I don't know who your host is but let's assume that your www directory is your initial web directory. What I mean this is the directory where your http://www.yourdoamin.com/index.html file is located. What you can do is place a file that contains your MySQL passwords in this directories sub-directory and include() or require() the file into your php page. This way no one can read them from a browser, and you might just have to assume that other people sharing your server can;t get into your directories, which is almost always the case.

I hope that helped...

Sorry.

If the PHP application running from the browser can read the file from the file system, then someone else on my server can also read the file from a script running as the browser username.

The only way I've found to do this is for the browser to be running setuid as me when it's accessing my files.

Virtual servers (freeVSD) support this. suEXEC configured browsers (Apache) support this. cgiWRAP supports this somewhat.

Most shared servers appear to be completely compromised when it comes to file security.

-t

cgiWRAP supports this somewhat yeah, that's a tough one... if there's a way to do that without setuid I'm not aware of it... boy, it'd sure be nice though... I'll let you know if I come accross something that acomplishes that... sorry

Originally posted by thewitt
How about a way to effectively read in the password in an encrypted form then decrypt it in the PHP application to use it? This would have to be done in a manner that would be hard to reverse engineer with the PHP source code, but... I was thinking about a binary distributed withe the application that did the encryption/decryption with a reversable algorythm that was not part of the PHP code...

I do not use PHP but PERL; however, we faced a similar problem when we were using shared hosting -- we have a dedidcated box now, which makes things much easier.

I am not positive as to your applications, but here is how we got around some of the problems by using the binary password solution you suggested.

In our application, we used PERL's crypt function to encrypt a password. We stored this password as a binary file on the server -- thus making it gibberish to anybody trying to read it through the command line. In our form to post to the script, we ask for the pass, encrypt it and then check it against the bin file. This works relatively well as a person has to write a script to access and read the bin file, dump it to text, and then run a password cracker to get the password. This is a lot of effort. We also stored these files in a directory that was not accessible by the web server. Eventually, our hosts installed CGIwrap, which eliminated part of these problems.

In my experience, I have found people snooping around on shared hosts are looking for the easy kill, e.g. a web page with 777 permissions by using a recursive find statement, you can almost always get your hands on a few of these files.