It’s better to use built-in session management functions included in PHP for secure and standardized session management. Possible security problems might occur if the server is not configured well for storing session information.
A common situation is when session contents are stored in files readable by all users that have an account on the web server (the classical /tmp directory). It’s best to store sessions in a database or in a part of the file system where only trusted users have access.
Other security risk situations involve session IDs, and the fact that they can be discovered by sniffers. For this reason session-specific traffic should be sent over SSL connection. PHP doesn’t need special configuration but the web server does (Apache).
It is very important to turn off register_globals parameter. Although it should be turned off by default (PHP version 4.2.0 and later) it must be checked anyway.
Before using values that an user submits through superglobal arrays such as $_GET, $_POST and $_COOKIE, they must be validated to make sure they don’t contain unexpected input.
In most cases the programmer knows what type of value is expecting so he can check if the input conforms. The easiest way to validate data is regular expressions.
If you want to transmit or receive private data (by hidden form), one way of doing this is to use hash functions. Hash a combination of a secret word (known only by the parts that are communicating) and the data to transmit and hash/rehash the result to verify the match.
Keeping up to date the PHP server with the latest patches and security problems is recommended. Also automatic PHP source display handler (AddType application/x-httpd-php-source .phps) should be used carefully, since it lets users see the code of the scripts.
From the two php.ini files that come with the distribution, the site configuration should be built based on php.ini-recommended, instead of php.ini-dist.
It’s indicated not to develop cryptographic schemes, and let PHP and its mcrypt extension for a standardized interface to many popular encryption algorithms to handle this task.
However strong the algorithm used, the keys that it uses and their storage are the most important issues involved. It’s advisable to transmit keys over SSL.
Cross-site scripting occurs when the scripts display unfiltered information to a browser. Command injection occurs when passing unfiltered, unescaped malicious commands to external applications or databases. So it’s advisable, in addition to input validations, to always escape user input before passing to other external processes or applications (databases).
Other problems occur when passing user input to a shell (exec(), system() commands). There are many operations that don’t need something else that PHP can’t do. If it’s absolutely necessary to filter the inputs using escapeshellcmd() for program names and arguments with escapeshellarg() (escapes any characters in a string that might be used to trick a shell command into executing arbitrary commands), and escapeshellcmd() (adds single quotes around a string and quotes/escapes any existing single quotes allowing you to pass a string directly to a shell function and having it be treated as a single safe argument).
PHP, unlike C/C++ programming languages don’t offer memory allocation functions and pointers, so the programmer doesn’t have to deal with such problems. Problems might occur with buffer overflows in PHP itself, or within its extensions. Keeping contact with to developer community for the latest patches and new releases is the best thing to do.
This FAQ comes directly from the horse's mouth on the PHP.net web site. It covers some of the most common problems faced by users, including installation, using databases, and migration from one version of PHP to the next.
" Although PHP 5 offers many new features, it's designed to be as compatible with earlier versions of PHP as possible with little functionality being broken in the process."