PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
Hi, I am kind of a novice with php and was wondering is code like this would be secure. Meaning would someone be able to access and get my database credentials or perform any other kind of attack?
I wouldn't put your connect statement in your code. You could place it in an include file. I'm sure others will have better suggestions which I too will be watching for
Yes. For example you can create a folder called "includes" or something. In a file here place your connect statement that contains passwords and such. Then your current code would be:
Lol, yeah exactly...but like you said what if the includes folder is not secured. Thanks for your help though, it is definitely better than what I had. Anyone know if the includes folder would be secure through this method?
If you look in your php.ini file you will see an entry for a path for include files. It is possible to place your include files into a secure folder that is referenced here so then you don't reference the path in the file that calls this include file. This makes the include file path less visible to the world. Additionally I would think you could set permissions appropriately on this folder that would allow your script to work, but keep you security info in your connect statment secure.
Just thought I'd add this to the discussion.
czerdrill wrote:What type of permission would be suitable? 644? or less? and which directive controls the include file for php?
I'm running IIS instead of apache, so I would try setting the permissions for "system" on the include path. The default when you install php I believe is inside the php folder, but since the default is always less secure I would change the path.
You can place the included file in a folder that is outside of the WWW path structure being served by IIS or apache. This will prevent it from being accessed via some hole in the http server.
Thanks eric and alicia for you help. I ended up putting a config file in my home/etc/includes folder and called it from there. So it should be secure! You guys are the best
Showing errors on a live server is a bit of a security risk, as it could give away vital information about file locations or server information. I wouldn't do it if I were you.
Good catch jackpf. I didn't see that little nugget.
Remove things like your line 5 where you dump out mysql_error. Also 'or die' is good for debugging, but long term you should put in real error handling instead of leaving the user with no clue and a dead app.
Yeah, just to expand once again, by using the trigger_error() function and set_error_handler() or something like that you can turn error reporting on on a dev machine, and off on the real thing.
Well, that doesn't help you when you're trying to debug something. You could have been redirected for a number of reasons - mysql not installed, bad credentials, etc....
Like I said, you should use the trigger_error() function. For example:
//in a file included in all pages, like a config file
$debug_mode = false;
if($debug_mode)
{
ini_set('display_errors', E_ALL);
}
else
{
ini_set('display_errors', 0);
function error_handler($err_no)
{
if(strcmp($err_no, E_USER_ERROR) == 0)
{
die('There was an error');
}
}
set_error_handler('error_handler');
}
//for queries/connections etc
mysql_connect('xxx', 'xxx', 'xxx') or trigger_error(mysql_error(), E_USER_ERROR);
That's basically an uncomplicated version of what I use.