PHP est soumis aux règles de sécurité
intrinsèques de la plupart des systèmes serveurs :
il respecte notamment les droits des fichiers et des dossiers.
Une attention particulière doit être portée aux
fichiers ou dossiers qui sont accessibles à tout le monde, afin de
s'assurer qu'ils ne divulguent pas d'informations critiques.
Puisque PHP a été fait pour permettre aux utilisateurs
d'accéder aux fichiers, il est possible de créer un
script qui vous permet de lire des fichiers tels que /etc/password,
de modifier les connexions ethernet, lancer des impressions de documents,
etc... Cela implique notamment que vous devez-vous assurer que les fichiers
accédés par les scripts sont bien ceux qu'il faut.
Considérez le script suivant, où l'utilisateur indique
qu'il souhaite effacer un fichier dans son dossier racine. Nous
supposons que PHP est utilisé comme interface web pour
gérer les fichiers, et que l'utilisateur Apache est
autorisé à effacer les fichiers dans le dossier racine des
utilisateurs.
Exemple 4-1. Une erreur de vérification de variable conduit à ... <?php
// efface un fichier dans un dossier racine
$username = $HTTP_POST_VARS['user_submitted_name'];
$homedir = "/home/$username";
$file_to_delete = "$userfile";
unlink ($homedir/$userfile);
echo "$file_to_delete a été effacé!";
?> |
|
Etant donné que le nom de l'utilisateur est à fournir, des intrus peuvent
envoyer un nom d'utilisateur autre que le leur, et effacer des
documents dans les comptes des autres utilisateurs.
Dans ce cas, vous souhaiterez utiliser une autre forme d'authentification.
Considérez ce qui pourrait se passer si les utilisateurs passent
"../etc/" et "passwd" comme arguments! Le code serait éxécuté
tel que :
Exemple 4-2. Une attaque du système de fichiers! <?php
// efface un fichier n'importe où sur le disque dur,
// où l'utilisateur PHP a accès. Si PHP a un accès root :
$username = "../etc/";
$homedir = "/home/../etc/";
$file_to_delete = "passwd";
unlink ("/home/../etc/passwd");
echo "/home/../etc/passwd a été effacé!";
?> |
|
Il y a deux mesures primordiales à prendre pour éviter
ces manoeuvres :
Voici un script renforcé :
Exemple 4-3. Une vérification renforcée <?php
// Efface un fichier sur le disque où l'utilisateur à le droit d'aller
$username = $HTTP_SERVER_VARS['REMOTE_USER'];
// utilise un mécanisme d'authentification
$homedir = "/home/$username";
$file_to_delete = basename("$userfile");
// supprime le chemin excédentaire
unlink ($homedir/$file_to_delete);
$fp = fopen("/home/logging/filedelete.log","+a"); //note l'effacement
$logstring = "$username $homedir $file_to_delete";
fputs ($fp, $logstring);
fclose($fp);
echo "$file_to_delete a été éffacé!";
?> |
|
Cependant, même cette technique n'est pas sans faille.
Si votre système d'identification permet aux utilisateurs
de créer leur propre login, et qu'un utilisateur choisi
le login "../etc/", le système est de nouveau exposé. Pour cette
raison, vous pouvez essayez d'écrire un script renforcé :
Exemple 4-4. Vérification de noms de fichier sécurisée <?php
$username = $HTTP_SERVER_VARS['REMOTE_USER'];;
$homedir = "/home/$username";
if (!ereg('^[^./][^/]*$', $username))
die('Erreur de nom de fichier');
//meurt, ne SURTOUT pas traiter!
//etc...
?> |
|
Suivant votre système d'exploitation, vous devrez protéger
un grand nombre de fichiers, notamment les entrées de périphériques,
(/dev/ ou COM1), les fichiers de configuration (fichiers /etc/ et .ini),
les lieux de stockages d'informations (/home/, My Documents), etc.
Pour cette raison, il est généralement plus sÛr d'établir une
politique qui interdit TOUT sauf ce que vous autorisez.
