Page 2 of 2

Re: Hiding your password in PHP code for logging into MySQL

Posted: Fri Aug 22, 2008 12:22 pm
by Eran
Mordred wrote:It sounds farfetched, but possible, so I concur that it's not free from "any" harm, as I originally said.
It is easily mitigated if you keep it outside of the web root (as one should wilth all include files), or with your original .htaccess proposal.

Also, it still does not refute my second argument about LFI, nor the third argument that with localhost-only database noone can use your login information even if he knows it.
I don't see how it is farfetched - I gave you an example of a famous case, and said it happened to me personally several times. That makes it actually pretty relevant.

I didn't understand your second argument about LFI - how can an include statement be manipulated? maybe if it used with a variable, but why would you need to do that?
Also, most people used shared environments, so the last argument is moot.

Re: Hiding your password in PHP code for logging into MySQL

Posted: Fri Aug 22, 2008 12:38 pm
by ghurtado
If by "far fetched" he was referring to the possible security hole that a config.php file leaves when PHP is not enabled on the server: well, not only is it not far-fetched, it is by far one of the most common vulnerabilities in PHP applications and one of the easiest ones to exploit. So it is quite the opposite of far-fetched.

http://www.google.com/search?hl=en&clie ... rt=40&sa=N

And that's without even trying!

Re: Hiding your password in PHP code for logging into MySQL

Posted: Mon Aug 25, 2008 5:44 am
by Mordred
pytrin wrote:I don't see how it is farfetched - I gave you an example of a famous case, and said it happened to me personally several times. That makes it actually pretty relevant.
I called it farfetched, because it's (currently) outside of attacker's control. (I still agreed that it's possible, and that measures should be taken). It is also possible that in the future there might be a vulnerability that will cause the PHP engine to fail. Good security measures protect against unforeseen attacks, so I very much agree that we should treat it as a real problem, and the config.php file should be kept outside of the web tree. You are right on this point and I concurred with it.
pytrin wrote:
Mordred wrote:Also, it still does not refute my second argument about LFI, nor the third argument that with localhost-only database noone can use your login information even if he knows it.
I didn't understand your second argument about LFI - how can an include statement be manipulated? maybe if it used with a variable, but why would you need to do that?
I can't speak for the "why" - ask the ones who do that. The fact is, that it happens often enough, as the flurry of RFI/LFI reports of yesteryear suggested.
In this scenario, config.php is better than config.ini, as the latter will leak the db credentials.
pytrin wrote:Also, most people used shared environments, so the last argument is moot.
I specifically stated
Mordred wrote:On a non-shared environment, this looks like a non-issue if you have the DB server configured to accept connections only from localhost.
The flame that started from that "non-issue" statement keeps dropping the "on a non-shared host ... localhost" part.

For the record: I fully agree that on a shared hosting there will be a problem if the db credentials are leaked (I don't have experience with administration so I can't give mitigation advice here)
I also stand behind my "non-issue" statement under the described limits. Let's stop fighting over it (unless someone has arguments that work without dropping half-sentences of what the other side said).

ghurtado wrote:And that's without even trying!
Well, maybe you should try. This argument is entirely in my favour, as it demonstrates what happens if the credentials file does not have a .php extension