Sécurité des fichiers

Sommaire

Issue lors de l'utilisation des octets nuls

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 PHP 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 manipulé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 #1 Une erreur de vérification de variable conduit à un gros problème


<?php
// Efface un fichier dans un dossier racine
$username = $_POST['user_submitted_name'];
$userfile = $_POST['user_submitted_filename'];
$homedir  = "/home/$username";

unlink("$homedir/$userfile");

echo "Ce fichier a été effacé !";
?>

Étant donné que le nom de l'utilisateur et le nom du fichier sont fournis, des intrus peuvent envoyer un nom d'utilisateur et un nom de fichier autres que les leurs, et effacer des documents dans les comptes des autres utilisateurs. Dans ce cas, vous souhaiterez utiliser une autre forme d'identification. Considérez ce qui pourrait se passer si les utilisateurs passent ../etc/ et passwd comme arguments! Le code serait exécuté tel que :

Exemple #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 = $_POST['user_submitted_name']; // "../etc"
$userfile = $_POST['user_submitted_filename']; // "passwd"
$homedir  = "/home/$username"; // "/home/../etc"

unlink("$homedir/$userfile"); // "/home/../etc/passwd"

echo "Ce fichier a été effacé !";
?>

Il y a deux mesures primordiales à prendre pour éviter ces manoeuvres :

Limiter les permissions de l'utilisateur web PHP.
Vérifier toutes les variables liées aux chemins et aux fichiers qui sont fournis.

Voici un script renforcé :

Exemple #3 Une vérification renforcée


<?php
// Efface un fichier sur le disque où l'utilisateur a le droit d'aller
$username = $_SERVER['REMOTE_USER']; // utilisation d'un mécanisme d'identification
$userfile = basename($_POST['user_submitted_filename']);
$homedir  = "/home/$username";

$filepath = "$homedir/$userfile";

if (file_exists($filepath) && unlink($filepath)) {
   $logstring = "$filepath effacé\n";
} else {
   $logstring = "Échec lors de l'effacement de $filepath\n";
}
$fp = fopen("/home/logging/filedelete.log", "a");
fwrite($fp, $logstring);
fclose($fp);

echo htmlentities($logstring, ENT_QUOTES);
?>

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 Vérification renforcée de noms de fichiers


<?php
$username     = $_SERVER['REMOTE_USER']; // utilisation d'un mécanisme d'identification
$userfile     = $_POST['user_submitted_filename'];
$homedir      = "/home/$username";

$filepath     = "$homedir/$userfile";

if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $userfile)) {
   die("Mauvais utilisateur/nom de fichier");
}

//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 stockage 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.

Rechercher une fonction PHP

Version en cache

21/11/2024 18:52:09 Cette version de la page est en cache (à la date du 21/11/2024 18:52:09) afin d'accélérer le traitement. Vous pouvez activer le mode utilisateur dans le menu en haut pour afficher la dernère version de la page.

Document créé le 30/01/2003, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/php-rf-security.filesystem.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.

Références

Manuel PHP : http://php.net

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.

Table des matières Haut