Les résultats des tests de plume pour l'application Web incluent un fichier d'un répertoire interdit qui n'est même pas utilisé ou référencé
Lors d'un récent test de plume d'une application Web, l'un des problèmes rencontrés était un "fichier de sauvegarde". Il s'agit d'un fichier javascript qui a été renommé en filename.js1 lorsqu'une version mise à jour de filename.js a été téléchargé.
Le "fichier de sauvegarde" vit dans un répertoire avec une liste interdite et n'est référencé ou utilisé nulle part dans l'application.
Comment ont-ils trouvé ce fichier?
Scanners de force brute
De nombreux scanners automatisés contournent les listes de répertoires interdits en recherchant des fichiers par "bruteforce". Cela signifie qu'ils rechercheront des fichiers supplémentaires avec des noms similaires aux fichiers existants (c'est-à-dire filename.js1 ainsi que des fichiers qui ne sont pas référencés du tout (aka secret.txt). Si vous avez un fichier dont le nom figure sur la liste bruteforced et se trouve dans un répertoire accessible, il sera trouvé, que la "liste des répertoires" soit activée ou non.
Il convient de souligner que les pirates informatiques font la même chose, c'est donc un vrai problème. En général, si quelque chose se trouve dans un répertoire accessible au public, vous devez supposer qu'il sera trouvé. Donc, si vous ne voulez pas qu'il soit public, vous devez le garder hors des répertoires publics - la désactivation de la liste des répertoires offre très peu de sécurité.
De vraies vulnérabilités
Enfin, cela peut ne pas sembler être un gros problème (et ce n'est probablement pas le cas), mais laisser des sauvegardes de fichiers javascript dans des répertoires publics est en fait une mauvaise idée en général. En ce qui concerne XSS, un attaquant aura généralement le plus de succès s'il est capable d'exploiter un fichier javascript hébergé sur le même domaine. En effet, cela permet de contourner un CSP ou d'autres "pare-feu" de sécurité. Par conséquent, si un ancien fichier javascript contenait une vulnérabilité de sécurité corrigée dans une version ultérieure, et qu'un attaquant a trouvé un moyen de forcer le navigateur de l'utilisateur à charger l'ancien fichier javascript, il peut enchaîner son chemin vers un vulnérabilité plus dommageable. Cela peut sembler tiré par les cheveux, mais enchaîner de nombreuses petites vulnérabilités en une plus grande est le nombre des pires violations qui se produisent.
tl/dr: Si quelque chose est hébergé par votre site Web mais n'a pas de raison d'être là, alors c'est un passif. Tuez-le avec préjugé.
Il existe de nombreux outils disponibles pour les noms de fichiers à force brute. Certains d'entre eux sont plus intelligents que d'autres.
Par exemple, un outil "stupide" peut simplement avoir une liste Word, contenant les noms probables des fichiers et des répertoires, tels que
/admin/wp-admin.phplogin.php
Un outil plus intelligent peut regarder les fichiers qu'il connaît déjà (par exemple en explorant l'application) et essayer de trouver des fichiers portant le même nom. Dans votre cas, il y avait un fichier nommé filename.js, donc l'application a probablement tenté de modifier le nom, comme TripeHound l'a souligné dans un commentaire:
filename.js1filename.js.bakfilename.bak.js.filename.js
Pourquoi ces fichiers posent-ils un problème?
On pourrait être tenté de penser qu'un fichier non référencé est "sûr", car il ne fait pas partie de l'application. Cependant, le fichier est toujours accessible, et selon le contenu du fichier, cela peut permettre à un attaquant de faire différentes choses:
- Un attaquant pourrait être en mesure de contourner un filtre URL et d'inclure un fichier JavaScript qui contient toujours des vulnérabilités d'une ancienne version.
- Les fichiers non référencés peuvent être des archives qui restent du déploiement et contiennent toujours du code source, permettant ainsi à un attaquant d'y accéder.
- Les fichiers non référencés peuvent contenir des informations d'identification ou d'autres données de configuration pertinentes
En général, il est préférable d'éviter d'avoir des fichiers non référencés dans votre racine Web. Comme son nom l'indique, ils ne sont pas utilisés par l'application et ne sont donc qu'une source de problèmes.
Le vrai problème ici est que vous avez un environnement de déploiement/production qui n'est pas contrôlé (et donc réplicable) via un système automatisé de contrôle et de déploiement des sources.
Cela signifie que, si vous trouvez un nouveau fichier dans votre système, vous ne savez pas s'il s'agit d'une sorte de porte dérobée supprimée par un kit racine, ou d'un fichier renommé inoffensif laissé par votre collègue.
En général, une meilleure pratique de sécurité consiste à n'avoir sur un serveur que des fichiers qui y sont placés par un script automatisé qui clone une sorte d'artefact de construction, et à ce que ce processus automatisé supprime également les fichiers qui ne devraient plus exister. Ensuite, vous pouvez exécuter des audits pour "les fichiers en production sont-ils ce que le système de construction dit qu'ils devraient être?"
Et si vous pensez que "les mauvaises pratiques de déploiement ne peuvent pas être un problème potentiellement mortel pour mon entreprise", je vous invite à google "Knight Capital Group".
De la même manière qu'un attaquant le ferait: en devinant.
C'est pourquoi vous avez des stylos testeurs: pour tester des choses auxquelles vous n'avez peut-être pas pensé.
Supprimez le fichier de sauvegarde de votre application afin qu'il ne soit pas accessible.
Comment ont-ils trouvé ce fichier?
Par une simple conjecture de "force brute", comme d'autres l'ont déjà mentionné.
Vous pourrez voir ce qui s'est passé, la demande pour ce fichier ainsi que les autres suppositions qui ont été faites, dans les journaux de votre serveur Web. À moins, bien sûr, que les testeurs ne parviennent à trouver une suspension qui leur permette de réinitialiser vos journaux (qui seront répertoriés dans votre rapport de test) ou que vous ne disposiez pas d'une journalisation suffisante activée.
mais être un renommeur moins prévisible n'est probablement pas une mauvaise idée non plus
Il est recommandé d'éviter que les anciens fichiers se trouvent dans le répertoire de votre application pas du tout. Même dans vos répertoires source, surtout si votre modèle de déploiement est "copier depuis la source".
Au lieu de conserver d'anciennes versions de fichiers pour référence ou pour d'autres raisons, utilisez les fonctionnalités offertes par votre système de contrôle de version. Tous les VCS vous permettront de récupérer les anciennes versions de fichiers, certains vous permettront de mettre les versions intermédiaires à l'écart sans les archiver correctement, vous pouvez utiliser la ramification pour séparer les travaux expérimentaux, etc.