MySQL login security on shared hosting

dbstraight · #1 05-20-2007, 01:30 AM

I have one question which will either be a deal-maker or deal-breaker:

Can I make it impossible to access my MySQL login credentials in my PHP scripts?

If they are in plain text or an included file, they are accessible.

Since modifying httpd.conf is impossible, it is impossible to use the preferred method on security sites of setting the username and password as environment variables and referring to them with $_SESSION.

With that in mind, can it be done? If not, no matter how attractive this shared hosting looks, I won't use it. If it can be done, I'm almost ready to sign up.

slapshotw · #2 05-20-2007, 03:19 AM

Quote:

Originally Posted by dbstraight

If they are in plain text or an included file, they are accessible.

If they're being parsed by the php processor, how are they accessible?

kmaw · #3 05-20-2007, 08:01 AM

Talk about re-inventing the wheel...

Serra · #4 05-20-2007, 09:09 AM

Quote:

Originally Posted by dbstraight

With that in mind, can it be done? If not, no matter how attractive this shared hosting looks, I won't use it. If it can be done, I'm almost ready to sign up.

Yea, that is a deal breaker. Since changes to httpd.conf are system wide, I can't see how that would be safer. When you use strange/bizarre configurations, you can't really be in the shared environment.

steve_a · #5 05-20-2007, 01:09 PM

You have directories that are not public to the web. You can put a file there and fread it.
I wouldn't say env vars are more secure. A php file is parsed unless it doesn't end in .php.

dbstraight · #6 05-21-2007, 12:56 AM

A PHP file is parsed under most circumstances, yes. If, however, someone on the same server as me used a PHP script to access one of my PHP scripts, they could get the source code. If the login credentials are in plain text, they're exposed. If the PHP script includes another file, they can just use a PHP script to get that file. Anything my PHP scripts can read can be read by other PHP scripts running on the same server with the same permissions.

charlesgan · #7 05-21-2007, 01:05 AM

definately you not going to put the login information in the .txt extension file. ANyone can just browse it and get it.

rename the file to "myconfig.php" for example, with .php.
and the setting is all within the <php>... thus no one can view it.
meaning you assign the setting to variable and store it, so at your calling page, you can use that value.

dbstraight · #8 05-21-2007, 01:11 AM

But someone CAN read it, that's the point. All they have to do is be on the same server and set up a PHP script to file_get_contents() of my PHP files, and they'll get the source code.

Suppose the web server runs as "nobody" on Linux. In order for PHP to access my file with my database credentials, the file has to be readable by "nobody" because PHP will run as "nobody." The problem is that EVERYONE'S scripts will run as "nobody," so everyone's scripts will have access to my file.

gtgeorge · #9 05-21-2007, 04:49 AM

Maybe you are asking the wrong questions. Perhaps you should ask about open_base_dir and phpsuexec....

quietFinn · #10 05-21-2007, 05:19 AM

Quote:

Originally Posted by dbstraight

Suppose the web server runs as "nobody" on Linux. In order for PHP to access my file with my database credentials, the file has to be readable by "nobody" because PHP will run as "nobody." The problem is that EVERYONE'S scripts will run as "nobody," so everyone's scripts will have access to my file.

No.
HostGator servers run PHPSuExec, which means that PHP is running using the account's username. This also means that one user's PHP scripts can NOT read other user's PHP (or any other) files.

Serra · #11 05-21-2007, 07:24 AM

Quote:

Originally Posted by dbstraight

But someone CAN read it, that's the point. All they have to do is be on the same server and set up a PHP script to file_get_contents() of my PHP files, and they'll get the source code.

I'm sure that is true on systems without any security, but I think you will find that most good hosts are running PHPSuExec.

As has been pointed out, you really need to ask the right questions instead of trying to get hosting companies to jump through hoops to meet your requirements, when they actually already meet and exceed your requirements.

dbstraight · #12 05-21-2007, 02:18 PM

My question here was "What can be done?" I don't see how that could be the wrong question.

Sadly, none of the sites I've read on PHP security, not even the PHP security consortium, bother mentioning this fact.

I guess it really is my fault for not looking into it more, but I've had an extremely difficult time finding good information. I was unaware of such protections. Thanks for answering my questions.

Serra · #13 05-21-2007, 03:54 PM

Quote:

Originally Posted by dbstraight

My question here was "What can be done?" I don't see how that could be the wrong question.

Its not wrong to ask the question, it was the way you asked it.

You will find it difficult to find the information you are looking for online, there isn't really a good place to go to get the 'real' information.

Shared hosting is plenty safe. In fact, the problems you are worried about are NOT the problems that you need to be worried about.