Se protéger de la faille LFI (Local File Inclusion)

Qu’est-ce que la faille LFI

La faille LFI tient son nom de Local File Inclusion (Inclusion de fichier local). Elle permet à un utilisateur d’inclure des fichiers locaux dans un site (appartenant au serveur sur lequel est hébergé le même site), et cela à partir d’une URL.

Keskidi?

En somme, un site web faillible peut permettre l’inclusion de fichiers arbitraires dans son propre contenu.

Ces fichiers peuvent très bien être en dehors du répertoire racine du site web. Des fichiers sensibles comme ceux contenant des données personnelles et notamment des mots de passe peuvent donc être inclus et récupérés.

Prenons un exemple, voulez-vous ?

On a souvent besoin d’inclure un fichier dans une page de façon tout à fait légitime comme sur l’exemple qui suit :

 http://exemple.com/vulnerable.php?page=menu.php

Seulement le fait de vérifier si ce fichier existe ne suffit pas, il faut s’assurer qu’il soit celui que l’on veut. (Et pas celui que n’importe qui choisit)

Que peut-on faire avec une faille LFI ?

Habituellement cette faille peut permettre de récupérer des informations comme les noms des utilisateurs de votre serveur et leurs mot de passe :

http://www.exemple.com/pagevulnerable.php?page=../../../../../../../../../../../etc/passwd

Exemple de fichier passwd qui peut s’afficher directement sur un site faillible.

On peut également récupérer le code source d’une page php ou exécuter des commandes PHP à distance en les postant vers une url spécifique.

Dans le pire des cas, un shell php peut être installé sur votre serveur afin d’autoriser un pirate à exécuter des commandes à distance.

Et shell dans le monde du hacking est en effet une interface « injectée » à travers une faille web permettant de servir de tableau de bord pour exploiter le système.

Comment savoir si mon site est faillible ?

Si votre site utilise une URL comme nous l’avons vu plus haut, il est possible qu’il soit faillible.

Voici un exemple typique de script php faillible :

<?php
   $fichier = $_GET['fichier'];
   if(isset($fichier))
   {
       include("pages/$fichier"); //inclut le fichier si il existe
   }
   else
   {
       include("index.php"); 
   }
   ?>

Par exemple, regardez si un utilisateur peut accéder aux fichiers de votre site :

Il faudra évidemment adapter le nombre de répertoire parents requis (../).

Si les ../ vous paraissent curieux depuis le début de cet article, il faut savoir que sous les systèmes Linux, cela signifie « dossier parent ».

Admettons pour cela un dossier appelé « dossier », présent à la racine du site. La racine étant « / ».

On a donc (architecture Linux) : /dossier.

Dans ce joli dossier, nous avons un sous-dossier :

/dossier/sous-dossier/

Et enfin un fichier dans ce même sous-dossier :

/dossier/sous-dossier/fichier

Attention, on complique les choses et l’on place un fichier motdepasse dans le dossier initial :

/dossier/sous-dossier/fichier
/dossier/motdepasse

Dans « dossier » on a donc « sous-dossier » (contenant lui-même « fichier ») et « motdepasse ».

Eh bien, même en nous trouvant dans le sous-dossier (là où est fichier), on peut chercher le fichier motdepasse en utilisant :

../../motdepasse

../ dit « dossier parent au dossier actuel », il s’agit donc de sous-dossier, c’est comme dire /dossier/sous-dossier.

Puis ../../ cherche encore le dossier parent de « sous-dossier », soit « dossier ».

Une fois dans le dossier cible, en passe à « motdepasse ».

Vous allez me dire: mais que fait-on à la base dans le « sous-dossier » en question ? Eh bien c’est tout simplement un dossier quelque part dans le système où se trouvent physiquement tous les codes sources du site web concerné ! Le système « travaille » donc à partir de ce dossier. Et les ../ sont relatifs à celui-ci.

Tout cela pour dire, qu’on peut naviguer entièrement dans le système de fichier et pointer les fichiers que l’on souhaite, à condition de connaître l’architecture… ou d’essayer à tâtons…

Et parfois il faut « revenir » dans beaucoup de dossiers parents, d’où l’enchaînement des « ../ ».

Comment se prémunir de la faille LFI ?

On va donc changer notre script précédent pour éliminer la possibilité d’utiliser « ../ » et forcer l’extension « .php »:

<?php
   $fichier= str_replace('../', '', $_GET['fichier']); //élimine ../
   if(isset($fichier))
   { //le fichier devra être inclus par son nom sans .php
       include("$fichier". ".php"); //ajoute ici le .php
   }
   else
   {
       include("index.php");
   }
   ?>

Pas mal ?

Vous pensez ?

Sachez cependant qu’il est possible d’utiliser l’encodage hexadécimal à la place des slashs car le navigateur les convertit correctement :

http://www.exemple.com/vulnerable.php?page=..%2F..%2F..%2F..%2F..%2Ffichier

Et il est aussi possible d’utiliser le NULL Byte %00 pour passer outre cette restriction.

Sur les nouvelles versions de Apache (un serveur web populaire) ce genre d’exploitation n’est maintenant plus possible car %2F et %00 ne sont pas gérés par sécurité. Cela dit vous pouvez tout de même ajouter cette ligne pour éviter la faille :

$fichier= str_replace(chr(0), '', $fichier); //chr(0) étant le null byte

<?php if ($_GET['page'] == “news”) {
    include(“news.php”);
} else {
    include (“accueil.php”);
}?>

Articles similaires