PERSONAL WEBSITE
BENOIT CHENU

Errors not to be made during the development of the site

A Web server can be quite protected, the largest security holes are often located in the application. Indeed a bad development can open doors.

3.1. Banish the global variables

In lower versions than PHP4 the variables of forms, cookie and session could be recovered simply by defining them. There are no distinctions between a variable passed in URL and a variable of session! We could then imagine the following example: when an administrator logs on a site, a session is launched and a variable admin is initialized to 1. To check if the administrator is really logged, in each page a test of this style is made:

if ($admin == 1)
{
	// Administrator is logged on...
}

It is then possible to anyone who logged on by passing in parameter to the URL: admin=1

Today, the register_global variable of PHP is set to off by default, which obliges to pass by $_get, $_post, $_cookie and $_session tables to recover the variables values. This was a step for a code a little protected. However, many providers kept this variable activated for compatibility reasons. In such a case, it is necessary to banish global variables by encapsulating the code in functions or classes without forgetting to use the tables listed previously.

3.2. Validation of form

When we integrate a form in a page, a user's seizure checking must be done. Two types of checking are often necessary: client side in Javascript and server side in PHP. However, what is a Javascript checking really worth? From a security point of view, nothing. Indeed, the code can be easily by-passed and the form sent without checking. In our case the Javascript must be only used to limit the seizure (a number of characters, numeric fields...), to specify errors instantaneously during the seizure, but mainly in an aim of limiting client/server transactions. The service side checking is not by-passable and must be implemented systematically.

For the POST or GET question, that must depend on imposed constraints of development. In both cases, hacking risks are present. Consequently, the submit method should not be selected for security reasons.

3.3. The passage of parameters

3.3.1. The file download

Making a files upload/download interface on a Web server presents many risks. A bad implementation could allow anyone to get the site sources and to send a php file containing a dangerous code. It is surprising to see the number of sites in this case.

Let us take the example of this site: http://www.esaee.com/uploads/index.php. This site places at the disposal some files. To download a file, it is enough to pass in parameter the file name. This is a simple method but many treatments and checkings must follow, but it is not the case here! It is then very easy to get site sources by simply passing the relative path (this software is used by hundreds other sites...).

The first interest to use a script to download a file on a server is to place those files in non accessible directories. This allows to affect access rights to files according to the connected clients. If this concept of access rights does not exist, the simplest is to place the files directly in a site directory.

To reach a file in a directory out of the site, the most secured method is to pass the md5 file in parameter. The server side checking can be then limited to a matching between the name of the file and its md5 stored in database. Another solution is to pass the name of the file. The server checking must then pass by a treatment of the parameter if this one contains unauthorized characters: \/:*?"<>|

3.3.2. Include

The include function allows including files in a PHP script. In the majority of the cases, this function is used to create dynamic pages by separating various elements constituting a page:

<?php
include 'config.php';
include 'header.php';
if (file_exists($page))
	include $page;
else
	include 'default.php';
include 'footer.php';
?>

This code is rather simple, it includes the configuration, the heading, checkings if the file to be included exists and includes it. Lastly, it includes the footer. This why, it is rather simple to by-pass script by modifying the contents of the $page variable by a sensitive file:

http://serveur/index.php?page=../../../../../etc/passwd

To secure such a fault, the simplest solution is to pass the name of the file without its extension; this one would be managed in script:

...
if (file_exists($page.'.php'))
	include $page.'.php';
...

The second solution is to remove those characters \/: thus avoiding changing directory.

If we reconsider this fault, if the passwd file is actually returned in our example, we are in a case where the Web server is launched under the user root! The majority of the passwd files are shadowed, which makes this method rather not very effective. However, another method of hacking consists in introducing code PHP into the server's logs then to consult those logs thanks to the fault, with an aim of executing this code. The idea is thus to pass code PHP in the URL (encoded with urlencode), generating an error of apache. It is then enough to call this file:

http://serveur/index.php?page=../../../../../var/log/httpd/error_log

This shows that it is thus a very significant fault (especially if the web server runs in root).

3.3.3. System

The function system allows to call systems commands directly. It is thus obvious that this function can involve considerable risks since if the attacker succeed to by-pass the script, he gains a partial access to the server (complete if httpd demon is launched in root).

It is important to not put commands by the URL (or POST) and to execute them directly. If you are obliged to, the protected method is still to limit commands. For that it is enough to initialize a matching table between the last parameter and the authorized command:

<?php
$command_list = array('kernel_version' => 'uname –sri', 'uptime' => 'uptime');
if (in_array($cmd, $command_list);
	system($command_list[$cmd]);
?>

For example, one wishes to show the kernel version of the server:

http://serveur/system.php?cmd=kernel_version

All this also applies to the others commands executing external applications like exec and shell_exec.

3.3.4. Mail

Just like the others previously quoted functions, a bad use of the mail function can be dangerous. This function is not really faulty but can be used with an aim of spam / mailbomb email addresses.

If we are on the provider level, to prevent that a user does not carry out spam, the most effective is to disable this function. However, it is also possible to re-code a personalized mail function (as make certain providers) by calling it for example email.

On the user level, precautions are also to be taken. In the case of sending mail by a form, it can be useful to limit the customer (to only one sending for example) by recovering his IP, this one stored in database. This will avoid to mailbomb the TO address while calling the Web page in loop.