Apache Security - Ivan Ristic [179]
Examine how a connection to the database is made. You do not want to see:
A connection based on trust (e.g., "accept all connections from localhost"). This would mean that any local user could gain access to the database.
A connection made with a root account. This account will typically have full access to the database system.
The web application should have minimal database privileges. It is acceptable for an application to use one account to access a database and have full privileges over it. It is not acceptable to be able to access more than one database (think about containment). The application privileges should be further restricted wherever possible (e.g., do not allow the account to drop tables, or give it read-only access to parts of the database).
The same concept ("least privilege used") applies to connections to other types of systems, for example LDAP.
Reviewing file permissions
When reviewing file permissions, we are interested in deviations from the default permissions, which are defined as follows:
Application files are owned by the application user (for example, appuser) and the application group (for example appgrp). The account and the group are not used for other purposes, which also means that no other users should be members of the application group.
Write access is not allowed.
Other users and groups have no access to application files.
As an exception, the web server user is allowed read access for files and is allowed read and execute access for CGI scripts (see Chapter 6).
We examine the potential for information leakage first, by understanding who is allowed read access to application files. If read access is discovered and it cannot be justified, the discovery is marked as an error. We automate the search using the find utility.
Examine if any suid or guid files are present. Such files allow binaries to run as their owner (typically root) and not as the user who is executing them. Their presence (though unlikely) may be very dangerous, so it is worth checking for them:
# find /home/application -type f -and \( -perm -4000 -or -perm -2000 \) | xargs ls -adl
The following finds world-readable files, where any system user can read the files and folders:
# find /home/application -perm -4 | xargs ls -adl
The following finds files owned by users other than the application user:
# find /home/application ! -user appuser | xargs ls -adl
The following finds group-readable files, where the group is not the application group:
# find /home/application -perm -40 ! -group appgrp | xargs ls -adl
Allowing users other than the application user write access opens a whole new attack vector and is, therefore, very dangerous. This is especially true for the web server user because it may be possible for an attacker to control the publicly available scripts to create a file under the application tree, leading to code execution compromise.
The following finds world-writable files:
# find /home/application -perm -2 | xargs ls -adl
The following finds files owned by users other than the application user. This includes files owned by the web server user.
# find /home/application ! -user appuser | xargs ls -adl
The following finds group-writable files, in which the group is not the application group (group-writable files are not necessary but there may be a good reason for their existence):
# find /home/application -perm -20 ! -group appgrp | xargs ls -adl
Reviewing the files
We now go through the file listing, trying to understand the purpose of each file and make a judgment as to whether it is in the right place and whether the permissions are configured properly. Here is advice regarding the different types of files:
Data
Datafiles should never