[prog] php, cgi-scripts, passwords and more

Allie Micka allie at pajunas.com
Thu Sep 11 07:02:23 EST 2003


> The passwords are stored in a php file along with the database access
> functions. Is there some way that I can protect that file so that noone
> except my user can read it? Or some other way to protect the passwords?

This should technically be your web host's responsibility, but you can 
check up on it to make sure.  Your concern is valid: in order for the 
web server to use your files it must have access to them.  And that is 
usually handled by having the files owned by your user and group/world 
readable so the web server can access all hosted sites.  So it seems 
logical that a nasty user hosting another domain could subvert apache 
to read your files, gaining access to your database credentials.

Someday, we'll be able to use apache2's perchild mpm more generally and 
a lot of these problems will go away.  Until then, we have safe_mode.  
safe_mode is a setting in php that, among other things, limits 
include(), require(), fopen(), etc. to files owned by the same user as 
the calling script.  So a file owned by you can open another file owned 
by you, but it can't open, say, /etc/passwd because it is owned by 
root.  Similarly, files owned by user badguy can't access your files 
because they're owned by different users.

The other setting your host should have used is open_basedir, which 
limits the directories your php scripts can open files in.  In most 
cases this should be set to your virtualhost directory and possibly a 
library directory.  So badguy's site is set with an open_basedir of 
/www/badguy.com , so he can't get at your files stored outside of his 
basedir in /www/yoursite.com

You can check up on these ini settings with phpinfo() or ini_get()

If all the above is set up properly, a) php protects your code from 
other scripts, b) filesystem ownership/suExec restrictions protect 
access through other means.  This leaves world-readability.  Make sure 
that the files are owned by the correct group (so the webserver can 
access them) and mode 640 .  You can read/edit them, the webserver can 
read them to serve them up, and other users on the system can't do 
anything.  It is also good to know whether the group is specific to the 
web process or if it is a more general group, that may have other users.

Last, make sure the include file itself is not accessible/downloadable 
to the public.  Many people recommend saving include files as .php so 
if someone tries to access them directly they'll execute and not 
display anything.  Why would you want people to remotely execute random 
chunks of code?  Even if it just fruitlessly sets a variable and then 
quits, why give people the option?

I prefer to name files .inc and make apache refuse to serve them.  By 
default, apache will serve .inc files as plain text (!), but you can 
add the following to your top-level .htaccess file:

<Files ~ "\.inc$">
     Order deny,allow
     Deny from all
</Files>

So if someone tries to access example.com/databasecredentials.inc 
they'll get an apache error.

The other to make include files inaccessible is to store them in a 
directory with an .htaccess file reading "Deny From All" .  None of the 
files in that directory will be served by apache but your scripts can 
still access them.

Keep in mind that, no matter what you do, someone at your hosting 
company has root access to the database and files.  Most hosts have 
better things to do with their time and wouldn't dream of doing 
anything nasty, but their terms of service don't always limit access 
and use.  The best last line of defense for your data is to encrypt 
sensitive stuff like passwords and credit card numbers, or move this 
information off the public host to a remote location.

Allie Micka
pajunas interactive, inc.
http://pajunas.com



More information about the Programming mailing list