[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