An Introduction to PHP Security

Since its introduction in 1994 or thereabouts, the PHP language has grown to become the most popular scripting language in the world of server side scripting and now powers most of the web’s most visited sites. With this popularity came new concerns such as performance, maintainability, scalability, reliability and (most importantly) security.

Security is abstract in any language, unlike language features such as conditional expressions or loops or any of the other characteristics. Security in a scripting language such as PHP is more developer-dependent than language-dependent. In other words, although the language offers you the tools to create secure code, it cannot prevent insecure code. Thus, the degree to which code is secure almost entirely depends on how security conscious a developer is.

This article will focus on PHP and shows you how to write secure code by leveraging PHP’s unique features, though the concepts that I’ll discuss here will be somewhat platform independent.

Web application security is a young and evolving discipline. During my six years of developing websites, I’ve learned that nothing is really totally secure, but if you know the features of a particular language well, you can write very secure code that will enable you to sleep well at night instead of worrying about the new attacks and techniques that are constantly being developed by those with malicious intentions.

There are things that you can do in your PHP installation to make developing websites more secure. We are going to be looking at some of these and also at other PHP features that makes PHP so easy to use.

{mospagebreak title=Register Globals}

Register globals have to be turned off for security reasons. All PHP developers should know this and make sure that it is the case in their PHP installations. There are two main reasons why this is necessary:

  • Globals that are turned on can increase the magnitude of a security vulnerability.
  • Globals that are turned on hide the origin of data, conflicting with a developer’s responsibility to keep track of data at all times.

The advantage of not turning off register globals is that the complexity of parsing raw form data is taken care of for you, and global variables are created from numerous remote sources. This makes writing PHP applications very easy and convenient, but it also poses a security risk. And I must also point out that register_globals on its own does not create a security vulnerability; the vulnerability comes as a result of the developer making a mistake. Having said this, register_globals must be disabled for your applications to be used widely, simply because most production environments will have their register_global settings turned off.

In most of the code that I will be using in this article and others that will follow, register globals will be disabled. You will see that I use super global arrays such as $_SESSION,$_POST and $_GET.

Note: If you ever have to develop an application that you think will be deployed in an environment where the register_globals is enabled, then make sure that you initialize all variables and set error reporting to E_ALL or E_STRICT. This is to alert yourself to the use of uninitialized variables, as any use of uninitialized variables is almost always a security risk when register_globals is turned on.

{mospagebreak title=Error Reporting}

Every developer makes mistakes and while most mistakes are harmless, some can also be a security risk. So, in the interest of writing efficient and risk free code, I would suggest that error reporting be turned on. This is particularly useful at the development stage of a project and will enable you to effectively debug code before deploying it.

PHP provides detailed information, and this information can be a security risk. So it is important to hide this information from the public. You can simply do it by setting display_errors to off. But how will you be able to see what errors are in your code? Well, the safest way would be to make PHP write those errors to a log. You do this by setting log_errors to on and indicate the location of the log with error_log.

Because the level of error reporting can cause some errors to be hidden, you should turn up PHP’s default error_reporting setting to at least E_ALL (E_ALL | E_STRICT is the highest setting, offering suggestions for forward compatibility, such as deprecation notices).

PHP error reporting is such that all error-reporting behavior can be modified at any level, so if you are on a shared host or are otherwise unable to make changes to files such as php.ini, httpd.conf, or .htaccess, you can implement these recommendations with code similar to the following:

ini_set(‘error_reporting’, E_ALL | E_STRICT);
ini_set(‘display_errors’, ‘Off’);
ini_set(‘log_errors’, ‘On’);
ini_set(‘error_log’, ‘/usr/local/apache/logs/error_log’);

Another feature of PHP error reporting is that it allows you to handle your own errors, with the set_error_handler() function:

  set_error_handler("my very own error handler");

This allows you to define your own function (my_error_handler( )) to handle errors; the following is an example implementation:

  function my_error_handler($number, $string, $file, $line,
$context) { 
    $error = "= == == == ==nPHP ERRORn= == == == ==n";
    $error .= "Number: [$number]n"; $error .= "String:
    $error .= "File: [$file]n"; $error .= "Line: [$line]n";
    $error .= "Context:n" . print_r($context, TRUE) . "nn";
    error_log($error, 3, ‘/usr/local/apache/logs/error_log’);

{mospagebreak title=Code Exposure}

Because PHP is a server side scripting language, it will frequently communicate with remote sources such as a database or HTTP clients such as web browsers, over a medium. In most cases this medium will be the Internet. And the Internet is a very public network, which means data exposure to the max. While data exposure in itself is not necessarily a security risk, exposure of sensitive data must be minimized at all costs. For example, when a user enters payment information, you should use SSL to protect credit card information as it travels between the client and your server. Also when displaying the credit card verification page, you are actually sending information back to the client, which again exposes the sensitive data on the Internet. This also merits the use of SSL.

Although using SSL protects the credit card information, it is not entirely safe (as it is just a encryption algorithm that can be broken some time in the future) and exposes the information on the Internet. The best approach, in this case, would be to eliminate the risk of exposure altogether by using only the last four digits or something similar when displaying the verification page.

In order to minimize the exposure of sensitive data, you must identify what data is sensitive, keep track of it, and eliminate all unnecessary exposure. For example, when retrieving data from a database, make sure only to retrieve the data that is needed, and not anything else. I’ve found that a lot of developers extract information from a database that is not needed. For example:

  $query = "SELECT name,password from usertable WHERE
name="’.$_POST[‘Aname’]."’ AND password=’".$_POST

The above query only checks in the name and password fields for the matching name and password. This only exposes data from those two fields. Now look at the query below:

$query = "SELECT * from usertable WHERE name="’.$_POST
[‘Aname’]."’ AND password=’".$_POST[‘Apassword’]."’";

The above query retrieves data from all the fields in the user table, and thus exposes a whole lot of data to the outside. You really don’t need to retrieve all of that data. So to minimize exposure, the first query is the best.

In the articles that follow, we are going to be looking at areas that present the most security risks:

  • Form data/URLs.
  • Database queries, including SQL injection.
  • Risks associated with handling files.

And a whole host of other areas.


In this introductory article we looked at what security vulnerabilities PHP has and how we can minimize them in applications. And we also looked at error reporting and data exposure. The next article will deal with the areas that provide the most common security vulnerabilities: form data and MySQL queries.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye