Les résultats du test du stylet pour l'application Web incluent un fichier d'un répertoire interdit qui n'est même pas utilisé ou référencé

Alfie

2019-08-27 16:02:53 UTC

view on stackexchange narkive permalink

Lors d'un récent test du stylet d'une application Web, l'un des problèmes détectés était un «fichier de sauvegarde». Il s'agissait d'un fichier javascript qui a été renommé en filename.js1 lorsqu'une version mise à jour de filename.js a été téléchargée.

Le 'fichier de sauvegarde' existe dans un répertoire avec une liste interdite et n'est pas référencé ou utilisé nulle part dans l'application.

Comment ont-ils trouvé ce fichier?

La supposition évidente est que pour chaque `file.js` qui _est_ référencé, ils essaient des choses comme` file.bak`, `file.js1`,` file.bak.js`, `file.js.safe` etc. etc..

Merci @TripeHound - c'était mon premier soupçon mais je voulais vérifier qu'il n'y avait pas d'astuces qui me manquaient.Plus d'efforts seront faits à l'avenir pour ne pas laisser ces fichiers dans les parages, mais être un renommage moins prévisible n'est probablement pas une mauvaise idée non plus.

@Alfie Oui, ça l'est.Cela masque le problème plutôt que de le résoudre.Oui, un fichier nommé `filename.js- {7bb744e7-b923-459b-a787-93ffe3b55ff0}` n'est probablement pas devinable, mais c'est comme dire "Je peux laisser ma porte déverrouillée car j'ai un tripmine juste derrière la porte".Efficace, mais l'approche complètement fausse.

@MechMK1 Je comprends que la sécurité par l'obscurité n'est jamais une bonne chose, mais si quelque chose comme celui-ci était à nouveau négligé, cela offrirait au moins un autre degré de protection, même s'il était petit.Inutile de leur faciliter la tâche, non?

@Alfie Oui, mais encore une fois, c'est fondamentalement la mauvaise approche.Automatisez votre déploiement.Assurez-vous qu'il n'y a * aucun moyen * pour les anciens fichiers de rester dans votre racine Web.Cela ne devrait pas être fait manuellement.

@MechMK1 compris;apprécier les conseils, merci.

Une meilleure utilisation du contrôle de version atténuerait la tentation de laisser traîner d'anciens fichiers. Du moins, c'est ce que je vois dans mon entreprise actuelle :-)

Euh ... s'il s'agissait d'un test de stylet, vous devriez avoir un rapport qui décrit comment ils ont trouvé le fichier.Ou était-ce une attaque non autorisée se faisant appeler un test de stylo?

@atk qui pourrait être dans un autre rapport de vulnérabilité, pure chance, force brute ou résultat d'un cycle de test précédent.Il est possible que la vulnérabilité montrant le fichier soit hors de portée du test (mais les informations ainsi obtenues ne le sont pas), il n'y a donc pas une telle description.

@Chieron dans tous ces cas, un rapport de test de stylo professionnel doit toujours indiquer comment le fichier a été découvert.Si ce n'est pas là, le client doit revenir vers eux et demander de corriger / compléter le rapport.(Et si ce n'est pas dans le contrat que tous les détails incluent des étapes pour reproduire - même si c'est "$ {scanner} l'a découvert, mais c'était hors de portée donc nous n'avons pas exploré" - alors cela devrait être dans le contrat.)

@atk Le test du stylo a été effectué par un client pour son propre bénéfice.Nous n'avons reçu les résultats que dans un format très limité.

@Alfie, si vous fournissez une solution cloud, le CLUF, les conditions de service et les contrats clients doivent indiquer explicitement s'ils sont autorisés à effectuer des tests au stylo et spécifier comment ils fournissent des résultats.Cela devrait inclure ce qu'ils doivent fournir en ce qui concerne les résultats des tests de stylo autorisés.

@Alfie, Si vous avez une solution sur site, vous devez la gérer comme n'importe quel autre bogue.Les clients peuvent modifier la configuration, et même le logiciel, et vous ne seriez pas en faute.Demandez les étapes à reproduire.S'ils ne le font pas, alors - comme tout autre bogue - faites de votre mieux pour identifier les éventuels défauts du produit et si vous n'en trouvez pas, dites au client les étapes de reproduction ou pas de solution.

@atk C'était un test autorisé, mais inclure des détails dans nos CGV concernant la manière dont les résultats doivent être fournis est une bonne idée que je ne suis pas sûr que nous implémentions actuellement.Je vais suivre cela, merci.

Scanners Brute Force

De nombreux scanners automatisés contournent les listes de répertoires interdits en recherchant "bruteforce" des fichiers. Cela signifie qu'ils rechercheront des fichiers supplémentaires avec des noms similaires à ceux des fichiers existants (c'est-à-dire filename.js1 ainsi que les fichiers qui ne sont pas référencés du tout (aka secret.txt ). Si vous avez un fichier dont le nom est sur la liste brute et se trouve dans un répertoire accessible, alors il sera trouvé, que la "liste de répertoires" soit activée ou non

Cela vaut la peine soulignant que les pirates 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 besoin de le garder hors des répertoires publics - la désactivation de la liste des répertoires offre très peu de sécurité.

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. Quand il s'agit de XSS, un attaquant aura généralement le plus de succès cesser s’ils sont capables 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 faille de sécurité qui a été 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 s'enchaîner à un vulnérabilité plus dommageable. Cela peut sembler exagéré, 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 ne le fait pas avoir une raison d'être là, alors c'est un passif. Tuez-le avec préjugé.

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 diverses choses:

Un attaquant pourrait être en mesure de contourner un filtre d'URL et d'inclure un Fichier JavaScript qui contient toujours des vulnérabilités d'une version plus ancienne.

Les fichiers non référencés peuvent être des archives qui restent du déploiement et qui 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 leur nom l'indique, ils ne sont pas utilisés par l'application et ne sont donc qu'une source de problèmes.