Les applications web modernes n’ont plus rien à voir avec ce qu’elles étaient autrefois. La bande passante quasi illimitée et l’espace de stockage indéfini qu’offre le cloud computing.
Les microservices qui surpassent l’architecture monolithique en décomposant les applications en petits composants indépendants. Les applications monopage qui chargent la plupart des ressources (y compris les éléments DOM principaux) une seule fois par cycle d’application, afin que vous puissiez utiliser le site en ne mettant à jour que le contenu dynamique requis.
Rapidité. Flexibilité. Intégration logicielle simplifiée. Compatibilité croisée. Rentabilité. En résumé, les applications web modernes sont de véritables concentrés de puissance. En même temps, elles restent facilement vulnérables aux attaques par inclusion de fichiers distants et locaux. Mais qu’est-ce qu’une attaque par inclusion de fichiers locaux (LFI) au juste ?
Qu’est-ce que LFI ?
Pour résumer, les LFI sont des vulnérabilités web rendues possibles « grâce » aux erreurs commises par les développeurs. En introduisant une faille de sécurité dans les applications web, des programmeurs négligents permettent à des utilisateurs non autorisés d’accéder à des fichiers, de s’emparer des fonctionnalités de téléchargement, de parcourir les informations disponibles, et bien plus encore.
Comment est-ce possible du côté des pirates ? Par le biais de la faille d’« inclusion dynamique de fichiers ». En exploitant les mécanismes d’inclusion que les développeurs mettent en place dans l’application, les cybercriminels peuvent injecter un fichier étranger dans le système d’origine. Il ne leur reste plus qu’à exécuter un simple script malveillant. Une fois que le script a accompli son œuvre, l’application est grand ouverte aux intrus, et vous en avez perdu le contrôle.
Mais pourquoi les applications web actuelles sont-elles si vulnérables aux attaques LFI ? Bonne question.
Le problème vient de tous les langages de script côté serveur dignes de ce nom. Plus précisément, du fait qu’ils s’appuient sur des inclusions de fichiers pour maintenir le code des applications web propre et bien organisé (ainsi que maintenable). En outre, les inclusions de fichiers permettent également aux applications web de lire des fichiers directement depuis le système de fichiers, d’activer la fonctionnalité de téléchargement, d’analyser les fichiers de configuration, et j’en passe.
Où est le problème, vous demandez-vous ? Le problème peut surgir — et surgit le plus souvent — du côté des programmeurs. Lorsque les mécanismes d’inclusion de fichiers ne sont pas correctement implémentés, des pirates expérimentés n’auront aucun mal à exploiter les capacités d’inclusion de ces mécanismes. En concevant et en exécutant une attaque LFI efficace, les cybercriminels peuvent divulguer des informations confidentielles, injecter un script intersite (XSS) ou déclencher une exécution de code à distance (RCE).
Cela paraît un peu flou ? Voyons de quoi il retourne, cas par cas.
Exemples d’inclusion de fichiers locaux
Parce qu’exploiter une vulnérabilité LFI est aussi simple techniquement que d’ajouter un fichier étranger au système de la cible, il existe de multiples façons pour les pirates de le faire. Voici les méthodes les plus répandues :
Le cas du fichier PHP
Selon les enquêtes Web Tech, pas moins de 79,2 % des sites utilisent PHP. Oui, 79,2 % de TOUS les sites, vous avez bien lu. Et PHP présente indéniablement des avantages. En même temps, ce même langage de script expose la plupart des applications web actuelles à des risques.
Comme vous le savez, les développeurs de sites et d’applications web qui utilisent PHP s’appuient sur ces deux fonctions pour inclure le contenu d’un fichier PHP dans un autre :
- La fonction include()
- La fonction require().
Ce qui distingue ces deux fonctions, c’est leur comportement face aux problèmes de chargement de fichiers. La première, include, émet un avertissement mais laisse le script continuer. La seconde, require, génère en revanche une erreur fatale, interrompant ainsi le script.
À quoi ressemblerait alors une attaque par inclusion de fichier PHP ? À quelque chose de ce genre :
https://example.com/?page=filename.phpVoici un exemple de code vulnérable à une attaque LFI. Lorsque les entrées ne sont pas correctement assainies, les attaquants peuvent sans difficulté modifier l’entrée (comme dans l’exemple ci-dessous) et manipuler l’application pour accéder à des fichiers restreints, des répertoires et des informations générales via la directive « ../ ». Généralement appelée traversée de répertoires (Directory Path Traversal), voici à quoi elle ressemble :
https://example.com/?page=../../../../etc/test.txtDans ce cas, il a suffi au cybercriminel de remplacer « filename.php » par « ../../../../etc/test.txt » dans l’URL et, et voilà, il a pu accéder au fichier cible. À ce stade, le ou les intrus pourraient téléverser un script malveillant sur votre serveur et y accéder par inclusion de fichier local.
Pour décomposer le processus, il comporte quatre étapes :
- Les intrus identifient une application web dont la validation des entrées utilisateur par le navigateur est insuffisante.
- La chaîne d’URL est modifiée à l’aide de la directive « ../ » pour permettre la traversée de répertoires.
- Le fichier .php malveillant est téléversé sur le serveur hôte via une porte dérobée, puis localisé grâce à la méthode de traversée de chemin.
- Le pirate est libre d’exécuter son script malveillant sur l’application hôte en raison d’une validation insuffisante.
Comment prévenir ce type d’attaque ?
Pour commencer, vous pouvez établir une liste blanche avec les paramètres de langue acceptés. Lorsqu’une méthode de saisie robuste n’est pas envisageable, vous pouvez recourir au filtrage des entrées et à la validation des chemins transmis. Ces méthodes permettent d’éliminer les caractères et combinaisons de caractères indésirables.
Cela dit, il vous faudra anticiper toutes les combinaisons de caractères problématiques. C’est pourquoi une solution plus pratique consiste à utiliser des instructions Switch/Case prédéfinies. Grâce à celles-ci, le système déterminera automatiquement quels fichiers peuvent être inclus, sans s’appuyer sur des paramètres d’URL ou de formulaire pour générer un chemin dynamiquement.
Le cas de la page affichée
Il vous arrivera parfois de devoir partager le contenu d’un fichier sur plusieurs pages web (comme c’est le cas avec les fichiers d’en-tête, par exemple). Cette approche est particulièrement pertinente lorsque vous souhaitez que les modifications se répercutent sur toutes les pages où le fichier est inclus. Ces fichiers peuvent être de simples fichiers HTML qui n’ont pas besoin d’analyseurs côté serveur pour être interprétés. Ils peuvent également servir à mettre en évidence des entrées de données distinctes, y compris des fichiers texte simples.
Imaginons que vous disposiez de plusieurs fichiers .txt contenant des textes d’aide et que vous souhaitiez les rendre accessibles via votre application web. Dans cette optique, vous pouvez les rendre visibles par un lien de ce type :
https://example.com/?helpfile=login.txtDans ce cas, le contenu du fichier texte est directement affiché sur la page, sans être préalablement stocké dans une base de données.
Comment cela peut-il entraîner une vulnérabilité d’inclusion de fichiers locaux ?
En l’absence de filtrage adéquat, les attaquants peuvent facilement modifier le lien ci-dessus comme suit :
https://example.com/?helpfile=../secret/.htpasswdIls peuvent ainsi accéder aux hachages de mots de passe contenus dans le fichier .htpasswd, ainsi qu’à l’ensemble des identifiants que ce fichier renferme habituellement. À l’aide de ces identifiants, les pirates informatiques peuvent alors accéder aux zones restreintes du serveur et y causer de graves dommages. Pire encore, ces mêmes hackers pourraient même être en mesure de lire des fichiers de configuration cachés contenant des informations sensibles (comme des mots de passe).
Quelle est la parade ?
En ce qui concerne les fichiers de page affichée, les contre-mesures les plus efficaces sont les mêmes que celles que vous appliqueriez contre les fichiers de téléchargement. Vous voulez savoir lesquelles ? C’est une bonne chose. Mais voyons d’abord ce qui caractérise ce cas.
Le cas du téléchargement de fichiers
Certains fichiers sont automatiquement ouverts par les navigateurs web lorsqu’on y accède, à l’instar des fichiers PDF. Lorsque vous souhaitez servir ces fichiers en téléchargement plutôt que de les afficher dans la fenêtre du navigateur, vous ajoutez des en-têtes supplémentaires qui indiquent au navigateur comment les traiter.
Avec un en-tête tel que Content-Disposition : attachment ; filename=file.pdf dans la requête, le navigateur ignore l’étape d’affichage et télécharge directement le fichier.
Par exemple, certaines entreprises proposent des brochures au format PDF afin que les visiteurs du site puissent les télécharger via un lien de ce type :
https://example.com/?download=brochure1.pdfComment cela peut-il créer une vulnérabilité LFI ?
C’est simple. Plus précisément, lorsque vous n’assainissez pas la requête, les attaquants peuvent demander à télécharger les fichiers sur lesquels l’application web elle-même est construite, leur donnant ainsi accès au code source. Ce faisant, ils peuvent localiser d’autres vulnérabilités de l’application web, ou « simplement » lire le contenu de fichiers sensibles.
Une autre mauvaise nouvelle est que les pirates peuvent combiner cet exploit avec la méthode de traversée de répertoires mentionnée précédemment. Ainsi, la même fonction pourrait leur permettre de lire le code source du fichier connection.php :
https://example.com/?download=../include/connection.phpEt, en supposant que ces pirates trouvent les valeurs de la base de données utilisateur, de l’hôte et du mot de passe (ce qui n’est pas un scénario improbable), ils seront également en mesure de récupérer la base de données à l’aide de ces identifiants volés. À ce stade, les cybercriminels auront les moyens d’exécuter des commandes de base de données et de compromettre la structure du serveur (à moins que l’utilisateur de la base de données ne dispose pas de privilèges d’écriture sur les fichiers).
Comment empêcher cela ?
- Enregistrez les chemins de fichiers dans une base de données et attribuez des identifiants individuels à chacun d’eux. Ainsi, les utilisateurs ne verront que l’identifiant et ne pourront ni consulter ni modifier le chemin du fichier.
- Établissez une liste blanche des fichiers vérifiés et sécurisés. De cette façon, vous pouvez ignorer tous les autres noms de fichiers et chemins d’accès.
- Ne placez pas de fichiers sur des serveurs web qui peuvent être — et le seront le plus souvent — compromis. Utilisez plutôt des bases de données.
- N’exécutez pas de fichiers dans des répertoires spécifiques. Assurez-vous plutôt que le serveur télécharge automatiquement les en-têtes.
Exemples réels de LFI
De nombreuses plateformes ont été victimes d’attaques par inclusion de fichiers locaux. Et, vous seriez surpris, ce ne sont pas seulement des petits sites qui ont subi des attaques LFI par le passé. En voici quelques exemples :
Conclusion
Les vulnérabilités d’inclusion de fichiers locaux ne sont pas à prendre à la légère. Certaines des plus grandes plateformes au monde en ont été victimes au fil des années, et la liste ne cesse de s’allonger. En même temps, tant que vous suivez les recommandations ci-dessus et restez vigilant, vous devriez pouvoir continuer à travailler sans encombre.
Mieux vaut prévenir que guérir : le guide ultime de prévention des attaques LFI
