Now a days PHP Language is very popular among developers to develop large applications like facebook etc.
So here I am going to tell how to secure your PHP applications in a simple steps
Contents
Disabling Remote URLs for File Handling Functions
File handling functions like fopen, file_get_contents, and include accept URLs as file parameters (for example:fopen('http://www.example.com/', 'r')). Even though this enables developers to access remote resources like HTTP URLs, it poses as a huge security risk if the filename is taken from user input without proper sanitization, and opens the door for remote code execution on the server. To disable this and limit file functions to local system, use the following setting in php.ini:
allow_url_fopen = Off
Network resources will still be accessible through fsockopen or CURL functions.
Most of the following settings are also located in the PHP configuration file php.ini. Its actual path depends on your OS. You may use the search feature to locate it if you don’t know where it is already.
Register Globals
Prior to version 4.2.0, PHP used to provide input values as global variables. This feature was named register_globals, and it was responsible for many security issues in web applications because it allowed attackers to freely manipulate global variables in many situations. Fortunately it’s disabled by default from PHP 4.2.0 and on, because it’s dangerous on so many scales. Do not enable it no matter what. If some script requires it then the script is most likely insecure. If a developer requests it to be enabled, then they are very likely to be incompetent. Don’t listen to them and keep it off!
register_globals = Off
Restricting What PHP Can Read and Write
More often than not, PHP scripts only need I/O access to a certain subdirectory in the filesystem,/var/www/htdocs/files for instance. In this case, you can limit what fopen and other file access functions can read and write to by using the following directive:
open_basedir = /var/www/htdocs/files
Safe Mode
PHP has a safe mode. In this mode, access to files not owned by Apache is disabled, and access to environment variables and execution of binary programs are also disabled.
In its default state, PHP’s safe mode is too restrictive for any advanced development to be possible. However, there are several settings to relax it. The biggest problem with safe mode is that only files owned by Apache are accessible to PHP scripts. This is often impractical when many developers are working on the same project, or when you want PHP to read a file without changing its ownership. Another affected situation is when you want PHP to read files generated by other programs. To work around this, there is a setting that checks for file group instead of owner:
safe_mode = Off safe_mode_gid = On
With safe_mode_gid enabled instead of safe_mode, PHP will be able to open files that belong to Apache’s group regardless of the owner. So if there are several developers working on the same server, add them to Apache’s group, make it their default group, and everything should be set.
Safe mode is also useful in stopping PHP from executing binaries, but sometimes you may need to let it run specific programs. In this case place these binaries (or symbolic links to them) in a directory (/var/www/binaries for instance) and use the following option:
safe_mode_exec_dir = /var/www/binaries
Finally, to allow access to certain environment variables, use the following setting, providing a comma-separated list of prefixes. Only environment variables which names begin with one of the prefixes will be accessible:
safe_mode_allowed_env_vars = PHP_
Posing Limits
It’s always a good idea to put limits on PHP’s execution time, memory usage, POST and upload data. To do this, use the following self-explanatory options:
max_execution_time = 30 ; Max script execution time max_input_time = 60 ; Max time spent parsing input memory_limit = 16M ; Max memory used by one script upload_max_filesize = 2M ; Max upload file size post_max_size = 8M ; Max post size
Needless to say, you may tweak the values to suit your needs.
Limit Access to Certain File Name Patterns
Many file extensions should not be accessible by end users. Take for example .inc. Some developers prefer to assign this extension to included scripts. The problem here is that this extension isn’t parsed by the PHP engine, and as a result, anyone can view the source code by requesting the file itself: http://www.example.com/includes/settings.inc
Such files may contain sensitive data like MySQL passwords. So you need to ensure that end users can not access those files. Other candidate extensions are .sql, .mysql, and .pgsql.
Another pattern to look out for is backup files. Some editors create backup versions of edited files in the same directory where the original file is located. For example, if you edit index.php, a backup called index.php~ will be created. Given that this file doesn’t end with .php, it will not be processed by the PHP engine, and its code will also be available to users by requesting http://www.example.com/index.php~
To avoid the risks mentioned above, you can use the following Apache directive:
<filesmatch> Order allow,deny Deny from all </filesmatch>
Place it in a .htaccess file or in Apache’s configuration. Adding more file extensions should be trivial to those familiar with regular expressions.
Error Messages and Logging
By default, PHP prints error messages to the browser’s output. While this is desirable during the development process, it may reveal security information to users, like installation paths or usernames. It’s highly recommended to disable this on a production server, and send error messages to a log file instead:
display_errors = Off log_errors = On
Hiding The Presence Of PHP
PHP reveals its presence on the server in a variety of ways: It may send an HTTP header (X-Powered-By: PHP), or append its name and version to Apache’s signature. In addition, there are easter egg URLs that return the PHP logo, one of them is: http://www.example.com/script.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
Obviously there is no reason to let end users know about the server’s PHP version. Luckily, there is a switch in php.ini that will disable all of the above:
expose_php = Off
