PHP Website Security Checklist

Today, web application security is an amazingly basic aspect of software development and deployment. With expanded hacking, malware and cyber-attack threats, business continuity must guarantee security for all enterprise-level web applications, particularly when those are critical from everyday activities perspective. This article traces a high-level checklist outlining the most common vulnerabilities of web applications and relevant PHP website solutions and best practices. Although focused on PHP, this checklist can be reached out to most of the programming languages.

Validation of Inputs

Advice:

• During development the configuration error_reporting = E_ALL (without removing the E_NOTICE) is used to recognise uninitialised variables; in production, errors should not be displayed in the web interface;
• filter_var () and filter_input () statements are very useful for filtering and validating inputs;
• The use of content equality and === type avoids errors during comparison with Booleans. The expression (0 == false) is true while (0 === false) is false;
• Casting can be faster than testing (compare the is_numeric function to an (int) $value type conversion);
• Beware of the $_REQUEST global super variable because it may contain values from many different sources;
• Check for different inputs using isset, for example isset ($ _ GET ['id']);
• Also pay attention to some fields in $_SERVER such as $_SERVER ['HTTP_REFERER'];
• As we cannot trust browsers, pass $_FILES ['file'] ['name'] through the basename function when uploading files; (imagine $_FILES ['file'] ['name'] = '../../../etc/passwd')
• Check the content of uploaded files. Images must be checked with the getimagesize() function, which returns false when the file is not of this type. Think also about the fileinfo extension;
• Do not accept serialised objects as input.

When all is said in done, it is fitting to utilize the idea of a whitelist for many cases of validation. An additional layer of protection or protection of a previously existing application can be given by including "PHP Input Filter" and "PHPIDS" or "mod_security" if you use Apache

SQL Injection

Utilizing raw SQL queries by concatenating variables to the query string is an awful practice that can undoubtedly prompt undesirable SQL injection.

Advice:

• Use prepared statements. In PHP the easiest way to handle escaping variables is to use an abstraction layer such as PDO.
• Parameterised queries are also accessible for some databases through basic PHP functions (e.g. postgresql or pg_prepare) or with extended libraries such as mysqli.
• If concatenation cannot be avoided, it is imperative to escape the variables using functions of the type “(real_) escape_string”. For mysql, for example, find out about the mysql_real_escape_string function. It is useful to add that the PHP manual advises against using this function, but it can be useful for quick securing of an old application.
• Avoid at all costs automatic techniques such as magic_quotes and/or generic add_slashes. Each database will react differently to these escape methods.

Cross-Site Scripting (XSS)

Consists of the use of javascript as input to be executed during display. This is a very common and dangerous vulnerability, although it is easy to avoid in many cases. You will find a fairly complete list of possible attacks on the OWASP website.

• Transform all characters of displayed variables into html entities. In PHP it is therefore often enough to pass all the variables displayed by the htmlentities function. Some “templating systems” such as “flexy” make an automatic escape;
• If you need to pass HTML in the variables, the strip_tags function can be used to filter permitted tags. However, this function is dangerous because of the javascript injection in the permitted arguments; e.g.: or link. It is, therefore, usually necessary to create your own filter function in addition to strip_tags;
• A good way to filter html is the “html purifier” class (http://htmlpurifier.org/, LGPL license).

In general, a generic display function must be written and used during any display.

Code Injection

Injection of malicious code that will be executed by the application.

• Avoid using variables in the include or require instructions. If it cannot be avoided, the use of whitelist filters is important;
• Avoid the “eval” instruction at all costs or treat it with the utmost care; (alternatives (http://www.php.net/manual/de/language.variables.variable.php), closures (http://www.php.net/manual/de/functions.anonymous.php) and the call_user_func()) function
• In php.ini, set allow_url_fopen to off if the function is not required.
• Avoid variables in preg_replace type functions.

Injection of Instructions

Some functions can be used to run system instructions.

• Avoid variables in instructions such as shell_exec, exec, system, passthru, popen;
• If they cannot be avoided, the escapeshellarg() and escapeshellcmd() functions must be used;
• Use whitelists and the basename function in filenames.

Session Security

By stealing the session identifier, other users’ sessions can be used. See “firesheep”, for example.

• Avoid using the session identifier in the URL because another site could steal the identifier by checking the “referer” or might even set your session identifier (imagine a link to a site such as a link?PHPSESSID=123). So set use_only_cookies to 1 or On in php.ini;
• Only use SSL (TLS) communications, otherwise, the session cookie may be intercepted on hostile networks. Require the session cookie to be communicated only in SSL: session.cookie_secure=1;
• Set an expiration time for sessions
• Associate visitor IP addresses with their sessions.

Cross-Site Request Forgery (XSRF)

Includes the utilization of the open session in another browser tab by a malicious web page. Most often the vulnerable parts will be forms which could be completed by a malicious site. For this situation, it is anything but difficult to evade this kind of assault by creating a unique identifier for the form and checking it during form submission. It is good practice to use a nonce created by a function such as uniqid or pseudo random hash with a secret code by using the hash_hmac function, which is placed in a hidden field on the form and in session, to be checked during submission. To protect non-form functionalities, a case-by-case analysis is required.

Best Practices for Storing User Passwords in the Database

Passwords must be stored in the database in hashed form. To do this, it is important, above all, not to use md5 or sha1 type algorithms, for which there are “rainbow tables”, which can be used to obtain the password quickly from the hash. In addition, specifically to avoid the use of rainbow tables, and to hide identical hashes from the same password, it is important to use a salt. This salt will be determined randomly and concatenated to the password before hashing. The salt and the hash will therefore be stored in the database.

It is also important to add a secret constant that would be stored somewhere other than in the database, for example in a configuration file. The use of a concatenated salt can be usefully replaced by a hash_hmac hash function, but we recommend the use of the crypt function (http://php.net/manual/en/function.crypt.php) which enables a cost factor to be added to the calculation when using CRYPT_BLOWFISH, CRYPT_SHA256 or CRYPT_SHA512 (see key stretching).

The hash calculation will then have the following form, for example:

$hash=crypt(hash_hmac('sha512','secret password',$saltsecretconfig), '$2y$’.$cost.'$randomsaltDB$') ;

The variable $cost will need to be set to a number such that the duration of the operation is viable for your application, but prohibitive for a brute-force attack (1/100 seconds for example). PHP 5.5 introduces new hash functions that enable secure storage of passwords (see http://www.php.net/manual/en/function.password-hash.php).

The function above becomes:

$hash = password_hash(hash_hmac(‘sha512’, ‘secret password’, $saltsecretconfig), PASSWORD_BCRYPT, ['cost'=>$cost]); // from PHP 5.5

Use of Countermeasures

In general, a web application will be scanned with an automatic tool by an attacker before compromise. It is, therefore, possible to place cyber traps or other “tar pits” on the application. A practical example called “weblabyrinth” can be downloaded from http://www.mayhemiclabs.com/content/new-tool-weblabyrinth. But useless scripts containing “sleep” functions or other false authentications can already perform this function.s

Webroot! = Approot

Placing libraries and other scripts in places that cannot be accessed directly from the Internet is a definite advantage. It means that libraries with vulnerabilities cannot be exploited directly.

Denial of Service

It is not possible to defend entirely against denial of service type attacks. However, it is possible to optimise applications so that they respond better. Although this is beyond the scope of this document, the following are some concepts that can be explored:

• Use “foreach” only for associative arrays and generally avoid any unbounded iteration on data from databases;
• Use a compiled code cache engine (memcache, eaccelerator, Zend Platform, …);
• Some debugging tools can report bottlenecks to you (xdebug, yslow, firebug, …)
• Compress your javascript;
• Check for slow queries (mysql_slow_query);
• Possibly compress server-client communication (only for heavy traffic and where the server CPU is sufficiently powerful);
• if you use Apache consider using the mod_evasion module.

Frameworks

Many frameworks are written by experienced developers and benefit from their extensive security experience and good programming practices. They often, therefore, include many of the techniques outlined above and enable web applications to be developed more quickly and securely. Examples: Zend, Symfony…

Advice for php.ini

The open_basedir configuration function is used to define the directories to which the application has access and therefore offers higher security. The following php.ini parameters should be set to the needs of your application while trying to keep them as low as possible. In general, it is advantageous to set these parameters on the fly with ini_set in scripts that need more resources than the bulk of the application:

• max_execution_time
• memory_limit
• post_max_size
• upload_max_filesize

Check this value in the production environment:

• display_errors = Off

Conclusion

Web application security, especially PHP Website security is something that is vital to ensure one doesn’t get hammered by cyber-attacks. There are globally accepted standards such as OWASP (Open Web Application Security Project) that prescribes best practices to ensure security vulnerabilities are checked, and web applications are built hack-proof.

Oditek has web security expertise, our development teams follow the OWASP guidelines, as well as test professionals, are equipped with security testing tools and methodologies. If you are needing an independent, comprehensive security tests report of your web-based applications OR build a secure, high performing web application, do reach out to us on info@oditeksolutions.com.