Quelle que soit la manière dont vous utilisez le fichier, vous devez spécifier le nom du fichier quelque part. Dans de nombreux cas, le nom du fichier sera utilisé comme paramètre de la fonction fopen(), et d'autres fonctions appelleront le handle qu'il renvoie :
<?php $handle = fopen('/path/to/myfile.txt', 'r'); ?>
La vulnérabilité survient lorsque vous incluez des données contaminées dans le nom du fichier :
<?php $handle = fopen("/path/to/{$_GET['filename']}.txt", 'r'); ?>
Puisque dans ce cas, le chemin et les parties de début et de fin du nom de fichier ne peuvent pas être manipulés par l'attaquant, les possibilités d'attaque sont limitées. Cependant, il est important de rappeler que certaines attaques utilisent NULL (représenté dans l'URL par nonether/chemin/vers/fichier
Comme c'est le cas pour de nombreuses attaques, l'utilisation de données corrompues lors de la construction d'une chaîne donne à un attaquant la possibilité de modifier la chaîne, ce qui entraîne un comportement non souhaité de votre application. Si vous prenez l’habitude d’utiliser uniquement des données filtrées pour créer des chaînes dynamiques, vous pouvez éviter de nombreux types de vulnérabilités, dont beaucoup ne vous sont pas familiers.
Puisque la partie statique principale du nom de fichier appelé par fopen() est /path/to, l'attaque ci-dessus implique plus de croisements de répertoires vers le haut que nécessaire. Étant donné que l'attaquant ne peut pas visualiser le code source avant de lancer l'attaque, une stratégie typique consiste à répéter la chaîne ../ trop de fois. Utiliser la chaîne ../ trop de fois ne détruira pas l'effet d'attaque ci-dessus, il n'est donc pas nécessaire pour l'attaquant de deviner la profondeur du répertoire.
Dans l'attaque ci-dessus, l'appel fopen() est conçu pour se comporter d'une manière que vous ne souhaitez pas. Il est simplifié. et équivalent à :
<?php $handle = fopen('/another/path/to/file.txt', 'r'); ?>
Après avoir pris conscience du problème ou subi une attaque, de nombreux développeurs commettent l’erreur d’essayer de corriger des données potentiellement malveillantes, parfois sans les vérifier au préalable. Comme mentionné au chapitre 1, la meilleure approche consiste à considérer le filtrage comme un processus de vérification et à forcer les utilisateurs à suivre les règles que vous définissez. Par exemple, si les noms de fichiers légaux ne contiennent que des lettres, le code suivant appliquera cette restriction :
<?php $clean = array(); if (ctype_alpha($_GET['filename'])) { $clean['filename'] = $_GET['filename']; } else { /* ... */ } $handle = fopen("/path/to/{$clean['filename']}.txt", 'r'); ?>
Il n'est pas nécessaire d'échapper la valeur du nom de fichier car ces données sont uniquement utilisées dans la fonction PHP et ne seront pas transmises au système distant.
La fonction basename() est très utile pour vérifier s'il y a des chemins inutiles :
<?php $clean = array(); if (basename($_GET['filename']) == $_GET['filename']) { $clean['filename'] = $_GET['filename']; } else { /* ... */ } $handle = fopen("/path/to/{$clean['filename']}.txt", 'r'); ?>
Ce processus est moins sécurisé que d'autoriser uniquement les lettres dans les noms de fichiers, mais il est peu probable que vous soyez aussi strict. Un meilleur processus de prévention en profondeur consiste à combiner les deux méthodes ci-dessus, notamment lorsque vous utilisez des expressions régulières pour vérifier la légalité du code (au lieu d'utiliser la fonction ctype_alpha(
)).
Lorsque toute la queue du nom de fichier est composée de données non filtrées, une vulnérabilité à haut risque se produit :
<?php $handle = fopen("/path/to/{$_GET['filename']}", 'r'); ?>
Donner plus de flexibilité aux attaquants signifie plus de vulnérabilités. Dans cet exemple, un attaquant peut manipuler le paramètre filename pour pointer vers n'importe quel fichier du système de fichiers, quels que soient le chemin et l'extension du fichier, car l'extension du fichier fait partie de $_GET['filename']. Une fois que le serveur WEB aura l'autorisation de lire le fichier, le traitement sera dirigé vers le fichier spécifié par l'attaquant.
Si la première partie du chemin utilise des données contaminées, ce type de vulnérabilité deviendra encore plus grand. C’est également le sujet de la section suivante.
Ce qui précède est le contenu du système de fichiers de sécurité PHP. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !