4.8.12.1 Tester l'inclusion de fichiers locaux

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Une vulnérabilité d'inclusion de fichier permet à un attaquant d'inclure un fichier, usuellement en eploitant un mécanisme d'inclusion dynamique de fichier implémenté dans l'application visée. La vulnérabilité survient à cause d'entrées utilisateur utilisées sans validation correcte.

Cela peut entraîner comme impact l'affichage du contenu du fichier, mais selon la criticité, cela peut aussi causer :

• L'exécution de code sur le serveur web
• L'exécution de code côté client, comme du JavaScript, qui peut permettre d'autres attaques comme le cross site scripting (XSS)
• Un déni de service (DOS)
• Des fuites d'informations sensibles

L'inclusion de fichiers locaux (aussi connue sous le nom de LFI : Local File Inclusion) est le processus par lequel on va inclure des fichiers déjà présents sur le serveur, en exploitant des procédures d'inclusion vulnérables implémentée par l'application. Cette vulnérabilité advient, par exemple, lorsqu'une page reçoit en entrée le chemin d'un fichier devant être inclus et que cette entrée n'est pas validée correctement, autorisant l'injection de caractères permettant de changer de répertoire (tels que point-point-slash). Bien que la plupart de nos exemples soient en PHP, c'est une vulnérabilité commune à d'autres technologies comme JSP, ASP, etc.

Comment tester

Comme les LFI adviennent quand des chemins passés à des instructions "include" ne sont pas correctement validés, dans une approche en boite noire, il faudra rechercher les scripts qui prennent des noms de fichiers en paramètres.

Considérons l'exemple suivant :

http://vulnerable_host/preview.php?file=example.html

Cela semble être l'endroit parfait pour tenter un LFI. Si un attaquant a assez de chance, et que le script inclut directement le paramètre au lieu de sélectionner la page dans un tableau, il est possible d'inclure arbitrairement tout fichier du serveur.

Une preuve de concept typique est de charger le fichier des mots de passe :

http://vulnerable_host/preview.php?file=../../../../etc/passwd

Si les conditions mentionnées plus haut sont réunies, un attaquant verra quelque chose ressemblant à :

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...

Très souvent, même quand de telles vulnérabilités existent, leurr exploitation est un peu plus complexe. Considérons le morceau de code suivant :

<?php “include/”.include($_GET['filename'].“.php”); ?>

Dans ce cas, un simple remplacement du nom du fichier ne fonctionnera pas puisque le suffixe '.php' est ajouté. Pour contourner cela, on utilise une technique avec des terminateurs octets nuls. Comme %00 indique la fin de la chaîne, tout caractère suivant cet octet spécial sera ignoré. Ainsi, la requête suivante retournera aussi la liste des attributs basiques des utilisateurs :

http://vulnerable_host/preview.php?file=../../../../etc/passwd%00

Références

• Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
• Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

Remédiation

La solution la plus efficace pour éliminer les vulnérabilités d'inclusion de fichier est d'éviter de passer des entrées utilisateurs à toute API de système de fichiers. Si ce n'est pas possible, l'application peut maintenir une liste blanche de fichiers pouvant être inclus dans la page, et utiliser un identifiant (par exemple l'index) pour accéder au fichier sélectionné. Toute requête contenant un identifiant invalide devra être rejetée, ainsi il n'y aura pas de surface d'attaque permettant aux utilisateurs malicieux de manipuler le chemin.