Apache Security - Ivan Ristic [40]
When this option is enabled, then even users whose browsers support cookies (and are thus using cookies for session management) will have their sessions invalidated if they follow a link from somewhere else back to your site. Therefore, since session.referer_check does not solve any problem in its entirety, I recommend that a proper session hijack defense be built into the software, as described in Chapter 10.
Setting Safe Mode Options
Safe mode (http://www.php.net/manual/en/features.safe-mode.php) is an attempt of PHP developers to enhance security of PHP deployments. Once this mode is enabled, the PHP engine imposes a series of restrictions, making script execution more secure. Many developers argue that it is not the job of PHP to fix security problems caused by the flawed architecture of server-side programming. (This subject is discussed in detail in Chapter 6.) However, since there is no indication this model will be changed any time soon, the only choice is to go ahead and do what can be done now.
Safe mode is implemented as a set of special checks in the PHP source code, and checks are not guaranteed to exist in all places. Occasionally, someone reports a hole in the safe mode and PHP developers fix it. Furthermore, there may be ways to exploit the functionality of PHP modules included in the installation to gain unrestricted access.
That being said, the PHP safe mode is a useful tool. We start by turning on the safe mode:
safe_mode = On
File access restrictions
The biggest impact of safe mode is on file access. When in safe mode, an additional check is performed before each filesystem operation. For the operation to proceed, PHP will insist that the uid of the file owner matches the uid of the user account owning the script. This is similar to how Unix permissions work.
You can expect problems in the following cases:
If more than one user has write access for the web server tree. Sooner or later, a script owned by one user will want to access a file owned by another.
If applications create files at runtime.
This second case is the reason programmers hate the safe mode. Most PHP applications are content management systems (no surprise there since PHP is probably the best solution for web site construction), and they all create files. (These issues are covered in Chapter 6.)
The easiest solution is to have the developer and Apache accounts in the same group, and relax uid checking, using gid checking instead:
safe_mode_gid = On
Since all PHP scripts include other scripts (libraries), special provisions can be made for this operation. If a directory is in the include path and specified in the safe_mode_include_dir directive, the uid/gid check will be bypassed.
Environment variable restrictions
Write access to environment variables (using the putenv() function) is restricted in safe mode. The first of the following two directives, safe_mode_allowed_env_vars, contains a comma-delimited list of prefixes indicating which environment variables may be modified. The second directive, safe_mode_protected_env_vars, forbids certain variables (again, comma-delimited if more than one) from being altered.
# allow modification of variables beginning with PHP_
safe_mode_allowed_env_vars = PHP_
# no one is allowed to modify LD_LIBRARY_PATH
safe_mode_protected_env_vars = LD_LIBRARY_PATH
External process execution restrictions
Safe mode puts restrictions on external process execution. Only binaries in the safe directory can be executed from PHP scripts:
safe_mode_exec_dir = /var/www/bin
The following functions are affected:
exec( )
system( )
passthru( )
popen( )
Some methods of program execution do not work in safe mode:
shell_exec( )
Disabled in safe mode
backtick operator
Disabled in safe mode
Other safe mode restrictions
The behavior of many other less significant functions, parameters, and variables is subtly changed in safe mode. I mention the changes likely to affect many