9.6. Prevent Include/Configuration File AccessWhen developing web based applications,
do not allow users to access (read) files such as the program include and
configuration files.
This data may provide enough information (e.g., passwords) to break into
the system.
Note that this guideline sometimes also applies to other kinds of applications.
There are several actions you can take to do this, including:
Place
the include/configuration files outside of the web documentation
root (so that the web server will never serve the files).
Really, this is the best approach unless there's some reason the
files have to be inside the document root. Configure the web server so it will not serve include files as
text. For example, if you're using Apache,
you can add a handler or an action for .inc files like so:
<Files *.inc>
Order allow,deny
Deny from all
</Files> |
Place the include files
in a protected directory (using .htaccess), and designate them as files
that won't be served. Use a filter to deny access to the files.
For Apache, this can be done using:
<Files ~ "\.phpincludes">
Order allow,deny
Deny from all
</Files> |
If you need full regular expressions to match filenames, in Apache you
could use the FilesMatch directive.If your include file is a valid script file,
which your server will parse,
make sure that it doesn't act on user-supplied parameters and that it's
designed to be secure.
These approaches won't protect you from users who
have access to the directories your files are in if they are world-readable.
You could change the permissions of the files so
that only the uid/gid of the webserver can read these files.
However, this approach won't work if the user can get the web server to
run his own scripts (the user can just write scripts to access your files).
Fundamentally, if your site is being hosted on a server shared with
untrusted people, it's harder to secure the system.
One approach is to run multiple web serving programs, each with different
permissions; this provides more security but is painful in practice.
Another approach is to set these files to be read only by your uid/gid,
and have the server run scripts at ``your'' permission.
This latter approach has its own problems: it means that certain parts of
the server must have root privileges, and that the script may
have more permissions than necessary. |
|