inlinetoc

Alors que la plupart des fichiers d'un serveur web sont directement gérés par le serveur lui-même, il n'est pas rare de trouver des fichiers non référencés et / ou oubliés qui peuvent être utilisés pour obtenir des informations importantes sur soit l'infrastructure soit les informations d'identification.

Scénarios les plus courants comprennent la présence de fichiers renommés des anciennes versions des fichiers modifiés, de fichiers d'inclusion qui sont chargés dans la langue de son choix et peuvent être téléchargés en tant que source, ou même de sauvegardes automatiques ou manuelles sous forme d'archives compressées. Les fichiers de sauvegarde peuvent également être générés automatiquement par le système de fichier sous-jacent sur lequel votre application est hébergée, une caractéristique généralement dénommé “snapshots”.

Tous ces fichiers peuvent fournir au testeur des informations sur le fonctionnement interne, les portes dérobées, les interfaces d'administrations, voire les identifiants pour se connecter à l'interface d'administration ou le serveur de base de données.

Une importante vulnérabilité se trouve dans les fichiers qui n'ont rien à voir avec l'application, mais sont créées à la suite de la modification des fichiers d'application, ou après la création à la volée des copies de sauvegarde, ou en laissant dans l'arborescence du site web des vieux fichiers ou des fichiers non référencés. Effectuer la modification sur place ou par d'autres mesures administration sur les serveurs Web de production peuvent, par inadvertance laisser, en conséquence, des copies de sauvegarde (soit générées automatiquement par l'éditeur lors de l'édition des fichiers, soit par l'administrateur dans un ensemble de fichiers compressés pour créer une copie de sauvegarde) .

Il est particulièrement facile d'oublier de tels fichiers, ce qui peut constituer une menace sérieuse pour la sécurité de l'application. Cela arrive parce que des copies de sauvegarde peuvent être générées avec les extensions de fichiers différentes de celles des fichiers originaux. Une archive .tar,. zip ou .gz que nous produisons (et oublier …) a évidemment une extension différente, et la même chose arrive avec des copies automatiques créées par de nombreux éditeurs (par exemple, emacs génère une copie de sauvegarde du fichier nommé ~ lors de l'édition du fichier). Faire une copie à la main peut produire le même effet (exemple une copie de fichier en file.old). Le système de fichier sous-jacent de l'application peut également faire des «instantanés» de votre application à différents points dans le temps (à votre insu!) Qui peuvent être également accessibles via le web, ce qui pose une menace semblable mais différente des “fichiers de sauvegarde” pour votre application .

En conséquence, ces activités génère des fichiers qui a) ne sont pas nécessaires à l'application, b) peuvent être traités différemment des fichiers d'origine par le serveur web. Par exemple, si nous faisons une copie de login.asp nommée login.asp.old, nous permettons aux utilisateurs de télécharger le code source de login.asp, en raison de son extension, login.asp.old sera généralement servi en text/plain, plutôt que d'être exécuté. En d'autres termes, login.asp provoque l'exécution du code côté serveur de login.asp, et login.asp.old met a disposition le contenu de login.asp.old ( le code côté serveur) pour être clairement renvoyé à l'utilisateur - et affiché dans le navigateur. Cela peut poser des risques pour la sécurité, car les informations sensibles peuvent être révélées. En règle générale, exposer le code côté serveur est une mauvaise idée, car non seulement vous exposer inutilement la logique métier, mais vous pouvez inconsciemment révéler des informations relatives aux applications qui peuvent aider un attaquant (chemins d'accès, structures de données, etc), sans oublier le fait qu'il y a trop de scripts avec les nom d'utilisateur / mot de passe intégrés en texte clair (ce qui est une pratique imprudente et très dangereuse).

Les autres causes de fichiers non référencés sont dus à des choix de conception ou de configuration lors de la détermination des différentes sortes de fichiers applicatifs tels que les fichiers de données, fichiers de configuration, les fichiers journaux, qui doivent être stockés dans des répertoires du système accessibles par le serveur web. Ces fichiers ont normalement aucune raison d'être dans un espace du système de fichiers qui peut être consulté via le web, car ils doivent être accessibles uniquement au niveau de l'application, par l'application elle-même (et non par l'utilisateur occasionnel de navigation autour!).

Les fichiers vieux, de sauvegarde et non référencés présentent diverses menaces à la sécurité d'une application web:

Les fichiers non référencés peuvent divulguer des informations sensibles qui peuvent faciliter une attaque ciblée contre l'application, par exemple inclure des fichiers contenant des informations d'identification de base de données, des fichiers de configuration contenant des références à du contenu caché, les chemins de fichiers absolus, etc Les pages non référencées peuvent contenir une fonctionnalité puissante qui peut être utilisée pour attaquer l'application, par exemple une page d'administration qui n'est pas liée à du contenu publié, mais peut être consultée par n'importe quel utilisateur qui sait où les trouver.

Les anciens fichiers et les sauvegardes peuvent contenir des vulnérabilités qui ont été corrigées dans les versions plus récentes, par exemple viewdoc.old.jsp peut contenir une vulnérabilité de path traversal qui a été fixée dans viewdoc.jsp mais peut encore être exploitée par toute personne qui trouve l'ancienne version.

Les fichiers de sauvegarde peuvent divulguer le code source des pages conçues pour s'exécuter sur le serveur, par exemple demander viewdoc.bak peut retourner le code source de viewdoc.jsp, qui peut être consulté pour les vulnérabilités qui peuvent être difficiles à trouver en faisant des requêtes à l'aveugle. Bien que cette menace s'applique évidemment aux langues scripts tels que Perl, PHP, ASP, scripts shell, JSP, etc, il ne se limite pas à eux, comme le montre l'exemple fourni ci-dessous.

Les archives de sauvegarde peuvent contenir des copies de tous les fichiers à l'intérieur (ou même à l'extérieur) de la racine du site. Cela permet à un attaquant d'énumérer rapidement l'ensemble de l'application, y compris les pages non référencées, code source, fichiers include, etc Par exemple, si vous oubliez un fichier nommé myservlets.jar.old contenant (une copie de sauvegarde) de vos classes d'implémentation de servlet, vous exposez beaucoup d'informations sensibles qui sont susceptible de décompilation et d'ingénierie inverse.

Dans certains cas, la copie ou la modification d'un fichier ne modifie pas l'extension de fichier, mais modifie le nom du fichier. Cela se produit par exemple dans les environnements Windows, où les opérations de copie de fichiers générent des noms de fichiers avec le préfixe «Copie de» ou des versions localisées de cette chaîne. Comme l'extension du fichier reste inchangée, ce n'est pas un cas où un fichier exécutable est retourné sous forme de texte par le serveur web, et ce n'est donc pas un cas de divulgation du code source. Toutefois, ces fichiers sont aussi dangereux car il y a une chance qu'ils comprennent une logique obsolète et erronée qui, lorsqu'ils sont invoqués, pourrait déclencher des erreurs d'application, ce qui pourrait donner de précieuses informations pour un attaquant, si l'affichage d'un message de diagnostic est activé.

Les fichiers journaux peuvent contenir des informations sensibles sur les activités des utilisateurs de l'application, par exemple des données sensibles telles que les paramètres d'URL, les ID de session, les URL visitées (qui peuvent divulguer le contenu supplémentaire non référencé). Les autres fichiers journaux (par exemple, les journaux ftp) peuvent contenir des informations sensibles sur la maintenance de l'application par les administrateurs système.

Les « instantanés » de systèmes de fichiers peuvent contenir des copies de votre code qui contiennent des vulnérabilités qui ont été corrigés dans les versions les plus récentes, par exemple ./snapshot/monthly.1/view.php peut contenir une vulnérabilité de directory traversal qui a été fixée dans /view.php mais qui peut encore être exploitée par toute personne qui trouve l'ancienne version.

Afin de garantir une stratégie de protection efficace, les essais devraient être complétés par une politique de sécurité qui interdit clairement les pratiques dangereuses, telles que:

La modification des fichiers sur place sur des systèmes de fichiers du serveur Web, du serveur d'application. Il s'agit d'une habitude particulièrement mauvaise, car elle est susceptible de générer des fichiers de sauvegarde au corps défendant des éditeurs. Il est étonnant de voir combien de fois cela est fait, même dans les grandes organisations. Si vous avez absolument besoin d'éditer des fichiers sur un système de production, faire en sorte que vous n'ayez pas laisser quoi que ce soit qui n'est pas explicitement prévu, et considérer que vous le faites à vos propres risques. Vérifiez soigneusement toute autre activité réalisée sur les systèmes de fichiers exposés par le serveur web, telles que les activités d'administration sur place. Par exemple, si vous devez prendre une photo d'un couple de répertoires (que vous ne devriez pas, sur un système de production …), vous pouvez être tenté de les archiver (zip/tar) d'abord. Veillez à ne pas oublier derrière ces fichiers d'archive! Des politiques appropriées de gestion de configuration devraient permettre de ne pas produire des fichiers obsolètes et non référencés. Les applications doivent être conçues pour ne pas créer (ou s'appuyer sur) les fichiers stockés dans les arborescences de répertoires web servis par le serveur Web. Les fichiers de données, fichiers journaux, les fichiers de configuration, etc doivent être stockés dans des répertoires non accessibles par le serveur web, pour contrer le risque de divulgation de l'information (pour ne pas mentionner la modification des données si les permissions des répertoires Web permettent l'écriture …). Les « instantanés » de systèmes de fichiers ne doivent pas être accessibles via le Web si votre racine est sur un système de fichiers utilisant cette technologie. Configurez votre serveur Web pour refuser l'accès à ces annuaires, par exemple sous apache une telle directive doit être utilisé:

<Location ~ ".snapshot">
   Order deny,allow
   Deny from all
</Location>

Les tests pour découvrir les fichiers non référencés utilisent des techniques à la fois manuelles et automatisées, et impliquent généralement une combinaison de ce qui suit:

Si ce n'est pas déjà fait, énumérer toutes les pages de l'application et des fonctionnalités. Cela peut être fait manuellement à l'aide d'un navigateur, ou en utilisant une outil spidering. La plupart des applications utilisent une combinaison de noms reconnaissables, et organisent les ressources en pages et répertoires en utilisant des mots qui décrivent leur fonction. Depuis le schéma de nommage utilisé pour le contenu publié, il est souvent possible de déduire le nom et l'emplacement des pages non référencées. Par exemple, si une page est trouvée viewuser.asp , alors cherchez aussi pour edituser.asp, adduser.asp et deleteuser.asp. Si un répertoire /app/user est trouvé, recherchez /app/admin et /app/ manager.

Beaucoup d'applications web laissent des indices dans le contenu publié qui peuvet conduire à la découverte de pages masquées et de fonctionnalités. Ces indices apparaissent souvent dans le code source de fichiers HTML et JavaScript. Le code source de tous les contenus publiés doit être examiné manuellement pour identifier des indices sur d'autres pages et de fonctionnalités. Par exemple:

Les commentaires des programmeurs et les sections commentées du code source peut se référer au contenu caché:

JavaScript peut contenir des liens vers des pages qui ne sont pas rendus au sein de l'interface graphique de l'utilisateur dans certaines circonstances:

var adminUser=false;
:
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp")); 

Les pages HTML peuvent contenir des formules qui ont été cachées en désactivant l'élément SUBMIT:

<FORM action="forgotPassword.jsp" method="post">
   <INPUT type="hidden" name="userID" value="123">
</FORM> 

Une autre source d'indices sur des répertoires non référencés est le fichier / robots.txt utilisé pour donner des instructions aux robots web:

User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include 

Dans sa forme la plus simple, il s'agit de la gestion d'une liste de noms de fichiers communs par le biais d'un moteur de requêtes afin de tenter de deviner les fichiers et répertoires qui existent sur le serveur. Le script netcat wrapper suivant lit une liste de mots à partir de stdin et exécute une attaque de base pour tenter de deviner :

#!/bin/bash
server=www.targetapp.com
port=80
while read url
do
echo -ne "$url\t"
echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile 

Selon le serveur, GET peut être remplacé par HEAD pour des résultats plus rapides. Le outputfile spécifié peut être filtré pour ne récupérer que les codes de réponse «intéressantes». Le code de réponse 200 (OK) indique généralement qu'une ressource valide a été trouvée (à condition que le serveur ne retourne pas un “non trouvé” à l'aide du code 200). Mais étudier également les codes 301 (Déplacé), 302 (trouvé), 401 (Non autorisé), 403 (Interdit) et 500 (erreur interne), qui peuventt également indiquer les ressources ou des répertoires qui méritent une enquête plus approfondie.

Cette attaque de base devrait être exécutée sur la racine du site, et aussi sur tous les répertoires qui ont été identifiés grâce à d'autres techniques. Une attaque avancé / ou plus efficace peut être réalisée comme suit:

Identifier les extensions de fichiers en cours d'utilisation dans des zones connues de l'application (par exemple, jsp, aspx, html), et utiliser une liste de mots de base annexé à chacune de ces extensions (ou utilisez une liste plus longue des extensions les plus courantes, si les ressources le permettent). Pour chaque fichier identifié par des techniques de dénombrement, créer une liste de mots personnalisée dérivée de ces noms de fichier. Obtenez une liste d'extensions de fichiers courants (y compris ~, bak, txt, src, dev, vieux, inc, orig, copie, tmp, etc) et utiliser chaque extension avant, après, et au lieu de l'extension du nom de fichier réel .

La façon la plus évidente par laquelle un serveur mal configuré peut divulguer des pages non référencées est à travers l'énumération des répertoires. C'est à dire permettre à tous les répertoires énumérés de fournir une liste des sous-répertoires. De nombreuses vulnérabilités ont été découvertes dans des serveurs Web individuels qui permettent à un attaquant d'énumérer le contenu non référencé, par exemple:

*Apache ?M=D directory listing vulnerability. 
*Various IIS script source disclosure vulnerabilities. 
*IIS WebDAV directory listing vulnerabilities

Les pages et fonctionnalités des applications Web orientées qui ne sont pas référencés dans l'application elle-même peuvent être référencé à partir d'autres sources du domaine public. Il existe différentes sources de ces références:

Les pages qui ont l'habitude d'être citées peuvent encore apparaître dans les archives des moteurs de recherche Internet. Par exemple, 1998results.asp peut ne plus être liée au site Web d'une entreprise, mais peut rester sur le serveur et les bases de données des moteurs de recherche. Cet ancien script peut contenir des vulnérabilités qui pourraient être utilisés pour compromettre l'ensemble du site. L'opérateur de recherche sur Google site: peut être utilisé pour exécuter une requête seulement contre un domaine de prédilection, comme dans: site:www.example.com. L'utilisation des moteurs de recherche de cette manière conduit à un large éventail de techniques qui peuvent vous être utiles et qui sont décrits dans la section Google Hacking de ce guide. Les fichiers de sauvegarde ne sont pas susceptibles d'être référencé par d'autres fichiers, et donc peut-être pas été indexés par Google, mais si ils se trouvent dans des répertoires « browsable » le moteur de recherche peut les connaître. En outre, Google et Yahoo gardent des versions en cache des pages trouvées par leurs robots. Même si 1998results.asp a été supprimé à partir du serveur cible, une version de peut encore être stockées par ces moteurs de recherche. La version mise en cache peut contenir des références à des indices ou à du contenu supplémentaire caché qui reste sur le serveur. Le contenu qui n'est pas référencé dans une application cible peut être liée par des sites tiers. Par exemple, une application qui traite les paiements en ligne pour le compte de tiers commerçants peut contenir une variété de fonctionnalités qui normalement ne peuvent être trouvée qu'en suivant les liens au sein des sites web de ses clients.

Parce que les filtres de liste noire sont basées sur des expressions régulières, on peut parfois profiter de fonctionnalités d'obscures fichiers OS ayant des extension pour lesquelles le développeur ne s'attendait pas à avoir le résultat retourné. Le testeur peut parfois exploiter les différences dans les la façon dont les noms de fichiers sont analysés par l'application, le serveur web, et l'OS sous-jacent.

Exemple: le nom de fichier sous Windows 8.3 “c: \ program files” devient “c:\program files” becomes “C:\PROGRA~1”

• Supprimer les caractères incompatibles
• Convertir les espaces en underscores
• Prendre les six premiers caractères du nom de base
• Ajouter “~ <digit>” qui est utilisé pour distinguer les fichiers avec des noms en utilisant les mêmes six premiers caractères
• Cette convention modifie après les 3 premiers ollisions cname
• Extension de fichier à trois caractères Tronquer
• Faire tous les caractères en majuscules

Pou découvrir les anciens fichiers et de sauvegarde en Boîte grise, il faut examiner les fichiers contenus dans les répertoires appartenant à l'ensemble des répertoires du serveur Web de l'infrastructure des applications web. Théoriquement, l'examen, pour être complet, doit être faite à la main, mais étant donné que dans la plupart des cas des copies de fichiers ou des fichiers de sauvegarde ont tendance à être créés en utilisant les mêmes conventions de nommage, la recherche peut être facilement scriptée (par exemple, les éditeurs laissent derrière eux des copies de sauvegarde en les nommant avec une extension reconnaissable, les humains ont tendance à laisser des fichiers avec une extension « ,old » similaire ou prévisible, etc).. Une bonne stratégie est celle de la planification d'une tâche périodique de vérification des antécédents pour les fichiers avec les extensions susceptibles de les identifier en tant que copie / sauvegarde de fichiers doublée d'une vérification manuelle à plus long terme.

• Les outils d'évaluation des vulnérabilités ont tendance à inclure des contrôles permettant de repérer les répertoires web ayant des noms standard (tels que “admin”, “test”, “backup”, etc), et de rendre compte des répertoires web qui permettent l'indexation. Si vous ne pouvez pas obtenir la liste de répertoires, vous devriez essayer de vérifier les extensions de sauvegarde probables. Voir par exemple Nessus (http://www.nessus.org), Nikto2 (http://www.cirt.net/code/nikto.shtml) ou son dérivé Wikto (http://www.sensepost.com/research/wikto/) qui supporte aussi stratégies fondées sur le Google Hacking.
• Les outils spider Web: wget (http://www.gnu.org/software/wget/, http://www.interlog.com/~tcharron/wgetwin.html); Sam Spade (http://www.samspade. org), Spike proxy inclut une fonction de moteur de recherche site Web (http://www.immunitysec.com/spikeproxy.html); Xenu (http://home.snafu.de/tilman/xenulink.html); curl (http://curl.haxx.se). Certains d'entre eux sont également inclus dans les distributions Linux standard.
• Les outils de développement Web incluent habituellement des outils pour identifier les liens rompus et les fichiers non référencés.