default configuration file for PHP, php.ini (usually located in / etc / php.ini in most Linux systems) contain a number of features that can be used to help protect your Web applications. Unfortunately, many PHP users and administrators are not familiar with the different options that are available in the php.ini file and leave the file in its own securities. Using some of the security-related options in the configuration file, can greatly improve the security posture of web applications on your server.
Safe Mode
PHP safe mode is an extensive "efforts to solve security problems shared server, which contains many useful features. Note that support safe mode will be removed in the sixth PHP Safe Mode if efficiently control the functions in one file on the server affect all other files have the same owner. For example, if you have a page script1.php trying to read the contents of a folder img /. Safe Mode with checkpoints UID and script1.php img / folder. If they match, then the script to access if they do not fit so safe mode will disable access. This is an interesting safety mechanism that allows you to restrict access by scripts directory outside the normal application installation. Safe Mode can cause problems even when the Web server ends up owning the files (for example, when a new file is uploaded or created by a application, it is usually owned by "apache" or a similar web server account).
Safe mode will also restrict executables that can be handled by scripts in the same way that restricts access to files and directories. Safe mode can also be configured so that only the binaries from a directory can be executed. This can help limit the exposure of the shell command scripts.
To enable safe mode, modify (or add) the safe_mode directive in php.ini to:
safe_mode = On
In some cases, you want to use a group to verify the property (for example, if you have several scripts for Web application deployment of people). To be sure to check the user group permissions to use:
safe_mode_gid = A
To restrict the directories, which may be associated with executable files, or use the following directives in the php.ini file:
safe_mode_include_dir = / path / to / dir
safe_mode_exec_dir = / path / to / exec / dir
Safe mode has many other useful functions that are of interest. Review the documentation on the website and see if PHP safe mode is adapted to its environment.
Include Limitation
Use PHP open_basedir made much sense since most file contains vectors of vulnerability. This directive restricts all PHP files in the specified folder and below. It is common for attackers to find ways to include local files from PHP scripts to detect local system files via the web server. For example, an attacker if a file inclusion vulnerability, they could try to include the file / etc / passwd to list all user accounts on the system. PHP with open_basedir is used to limit the inclusion of files to the web root, eg / var / www. Once you put the files outside this directory can not be included in scripts, so the above attacks will fail. To enable the open_basedir to update your php.ini to include:
open_basedir = / path / to / web / root
Disable functions
There are some features in PHP that you probably do not want your developers to use because of the danger they represent. Even if you know your users not to use certain functions, it is wise to disable them completely so that an attacker can not use them. This safeguard is particularly effective in stopping an attacker who managed to upload a PHP script that writes a file system, or even include an external file PHP. By disabling the feature ensures that you can limit the effectiveness of these types of attacks. It should be noted that it is almost impossible to do anything to prevent an attacker to execute a command on a shell disabling features, but it certainly can stop an attacker who is not a good PHP programmer.
To disable functions like shell_exec () and system () can prevent users and attackers to use these functions. It is important to limit the functionality for developers, because the use of these commands open the possibility of the vulnerability of remote code execution if not used carefully. Certainly, there are cases of operations such as executing a command shell, but a pack of PHP provides functions that are essentially the same. Developers can standardize on one of these functions and the rest can be disabled to avoid attacks. If this is not a foolproof solution is likely to prevent attacks like the terrible C99 shell. To enable the disable_functions directive can simply add to your php.ini file with a list of comma-separated functions to be restricted. For example:
disable_functions = php_uname, getmyuid, relays getmypid, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, executive system, highlight_file, source, show_source, fpaththru, virtual posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid , posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname , proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo
Avoid disclosure
Attackers often use information exposes your web server for information about configuring the server, the application and components. Error messages are among the most common forms of disclosure of information, often information leakage as the installation path of applications, database connectivity, data model details such as table and column names, and details such as script variables. Although this information is invaluable for debugging developer, is useless for end users and dangerous to expose the attackers. PHP debugging output should be disabled in php.ini:
display_errors = Off
This prevents PHP error at run time in the pages sent to users. PHP will continue to log errors as usual, however, so they can be examined by developers. Beware development tactics to stop the execution of PHP errors, however, that disabling this feature does not preclude disclosure of information. Some developers may use the custom debug output embedded in HTML comments, FirePHP third party tools or to write PHP error logs using local guides. Htaccess and the error_log directive. However, preventing the display of errors by default, reduce the opportunity to present information to the attackers.
Disable Globals
Global variables are not horrible for PHP 3 days. Most of the distribution of global variables in the registry is set to OFF (and, fortunately, is not supported in future versions of PHP). However, you must ensure that the directive is properly in place. You should find the following in php.ini:
register_globals = Off
Register Globals variables allows HTTP to be used without indicating their source. For example? If a developer wants to use a URL variable named 'id', for example, the URL request index.php id = 4, with globals, they can simply use $ instead of $ id ['id'] _GET. It is a great convenience, but it can cause collisions. For example, a post of shape if you use a variable called "id" and there is a variable $ id is set in a script and a user changes the URL of the script to include an "id =" in the URL, variable that has priority? Even more damaging is the possibility for hackers to change the configuration variables as the DOCUMENT_ROOT from the URL. This can cause endless problems, especially if the attackers are able to call scripts that are normally included in other scripts and expect predefined variables which can be replaced by GET variables to a hacker.
Many older programs may require global register variables. If so, at least limit the configuration files specific application instead of all your PHP installation. You can do this using PHP directives. htaccess file included in specific folders. Make sure register_globals is off, but in your php.ini!
Delete remote file contains
Attackers often try to identify the file inclusion vulnerabilities in applications and then use it to include malicious PHP scripts they write. Even if an attacker has write access to files of the web application if the inclusion of remote files allowed the attacker can host malicious PHP scripts on other web servers and applications will be downloaded and run locally! This can have devastating consequences. To limit the execution of remote files to be sure of the following in php.ini:
allow_url_fopen = Off
allow_url_include = Off
This prevents remote scripting to be included and executed by the scripts on your system.
Updates Restrict file
If you do not use the upload feature one of your PHP scripts so it's a good idea to turn it off. Attackers will try to file (wrong) to download to quickly inject malicious scripts into web applications. By disabling file downloads completely, which makes moving scripts on your web server more difficult. To disable file uploads file_uploads change directive in php.ini as follows:
file_uploads = Off
Even if you allow the download of files, you must change the default temporary folder used for downloading files. This can be done by changing the upload_tmp_dir directive. You can also choose to limit the size of files that can be downloaded. This is usually a change of system administration of a security patch, but it may be useful. Use the upload_max_filesize directive to that effect. To limit the downloading of files and file sizes change your php.ini file so it reads:
upload_tmp_dir = / var / php_tmp
upload_max_filezize = 2M
Secure Sessions
Popular flight session is an attack that allows an attacker to hijack the session of a legitimate user. Using session hijacking an attacker can bypass portions of the authorization and access applications to the Web without permission. PHP uses strong (which means long-generated pseudo random) session identifiers to guess a session ID is extremely difficult. When connected to a PHP application, you can see in your browser and can identify a cookie with a name like "PHPSESSID" and a value similar to 'bbbca6bb7a23bdc8de3baef2b506e654. The cookie consists of 32 hexadecimal characters, which makes it extremely difficult to predict. The flaw in this system, however, is that session IDs are written to the file system where PHP can be created to track them. Change the default location for session identifiers confound attempts to read. To change the location where information is written in the session to change the session.save_path in the php.
ini settings, so that it points to the desired position like this:
session.save_path = / var / lib / php
Make sure your web server can read and write to the location you specify, however, or sessions will not work. You can also set the PHP, it writes the cookie to be inaccessible to JavaScript. If you do not have PHP applications that use JavaScript to manipulate cookies is an excellent idea. Hackers often use Cross Site Scripting (XSS) bugs in web applications to inject JavaScript code into pages that can be used to steal session cookies. By setting the php.ini directive:
session.cookie_httponly = 1
JavaScript you limit access to your cookies. Another safety feature some PHP to check the values HTTP judge, the session information is not disclosed internally while a user views an application. This prevents users from accidentally disclose information about the session in a manner that will allow users to track external links and steal one session. This is particularly useful if information about the session is being adopted in a URL that could accidentally be released on a mailing list or website. To enable this feature, you must use the following in php.ini:
session.referer_check = your_url.tld
