Les extensions de fichiers sont couramment utilisés dans les serveurs web afin de facilement déterminer quelles technologies / langues / plugins doivent être utilisés pour satisfaire la demande.

Bien que ce comportement est compatible avec les RFC et les normes Web, l'utilisation des extensions de fichiers standard fournit des informations utiles sur pénétrer les technologies sous-jacentes utilisées dans une applications Web et simplifie grandement la tâche pour déterminer le scénario d'attaque qui sera utilisé sur des technologies particulières.

En outre, une mauvaise configuration des serveurs web peut facilement révéler des informations confidentielles sur des informations d'identification d'accès.

La vérification des extensions est souvent utilisée pour valider les fichiers devant être téléchargés, ce qui peut conduire à des résultats inattendus si le contenu n'est pas ce qui est attendu, ou en raison de noms de fichier différents de ceux attendus par l'OS

Déterminer la façon dont un serveur Web traite les demandes correspondant à des fichiers ayant des extensions différentes peut nous aider à comprendre le comportement du serveur Web en fonction du type de fichiers auquel nous essayons d'accéder. Par exemple, cela peut nous aider à déterminer les extensions de fichier qui sont retournés comme text / plain en opposition à celles qui provoquent une exécution sur le serveur. Ces dernières sont indicatives des technologies / langues / plugins qui sont utilisés par les serveurs Web ou serveurs d'applications, et peuvent fournir des informations supplémentaires sur la façon dont l'application Web a été conçue. Par exemple, une extension “.pl” est généralement associée à support Perl côté serveur (même si l'extension de fichier seule peut être trompeue et pas entièrement concluante, par exemple, les ressources Perl côté serveur peut être renommées pour cacher le fait qu'elles sont en effet liées à Perl). Voir également la section suivante sur les «composants du serveur Web» pour plus d'informations sur l'identification des technologies côté serveur et des composants.

Soumettre des demandes http[s] concernant ses extensions de fichiers différents et vérifier comment elles sont traitées. Ces vérifications doivent être faites sur la base d'un répertoire web.

Vérifier les répertoires qui permettent l'exécution du script. Les répertoires du serveur Web peuvent être identifiés par les scanners de vulnérabilités qui testent la présence de répertoires bien connus. En outre, établir la structure du site web nous permet de reconstruire l'arborescence des répertoires web distribuées par l'application.

Si l'architecture de l'application Web est équilibrée, il est important d'évaluer l'ensemble des serveurs Web. Cela peut ou peut ne pas être facile, en fonction de la configuration de l'infrastructure d'équilibrage. Dans une infrastructure avec des composants redondants il peut y avoir de légères variations dans la configuration de chaque serveurs d'applications, ce qui peut se produire, par exemple, si l'architecture Web utilise des technologies hétérogènes (pensez à un ensemble de serveurs Web IIS et Apache dans une configuration avec équilibre de charge, ce qui peut introduire une légère comportement asymétrique entre eux, et des vulnérabilités éventuellement différentes).

Exemple:

Nous avons identifié l'existence d'un fichier nommé connection.inc. La tentative d'accéder elle donne directement vers son contenu, à savoir:

<?
       mysql_connect("127.0.0.1", "root", "")
       or die("Could not connect");

?>

Nous avons déterminé l'existence d'une SGBD backend MySQL ainsi que les informations d'identification (faible) utilisées par l'application Web pour y accéder. Cet exemple (qui a eu lieu lors une véritable évaluation) montre combien peut être dangereux l'accès à certains types de fichiers.

Les extensions de fichiers suivantes ne doivent JAMAIS être renvoyées par un serveur web, car ils sont liés à des fichiers qui peuvent contenir des informations sensibles, ou à des fichiers pour lesquels qui n'ont aucune raison d'être servis.

.asa 
.inc 

Les extensions de fichiers suivantes sont liées à des fichiers qui, quand on y accède, sont soit affichés ou téléchargés par le navigateur. Par conséquent, les fichiers avec ces extensions doivent être contrôlés pour vérifier qu'ils sont effectivement censés être servis, et qu'ils ne contiennent pas d'informations sensibles.

... Zip, tar, gz, tgz, rar, ...:.. (Compressés)  fichiers d'archive
. Java: Pas de raison de donner accès aux fichiers source Java
. Txt: Les fichiers texte
. Pdf: les documents PDF
. Doc, rtf, xls, ppt, ...:.. Documents Office.
. Bak, anciennes extensions et autres indicatif des fichiers de sauvegarde (par exemple: ~ pour les fichiers de sauvegarde d'Emacs).

La liste donnée ci-dessus n'est pas exhaustive car les extensions de fichiers sont trop nombreux pour être complètement traitée ici. Reportez-vous à http://filext.com/ pour une base de données plus complète des extensions.

Pour résumer, afin d'identifier les fichiers selon leur extension, un mélange de techniques peut être utilisée, y compris: le scanners de vulnérabilité, spidering et mirroring tools, l'inspection manuelle de l'application (ce qui permet de surmonter les limitations dans les outils de spidering), l'interrogation des moteurs de recherche ( voir Testing: Spidering et googling). Voir aussi Testing for Old, Backup and Unreferenced Files qui traite des questions de sécurité liées aux fichiers “oubliés”.

Le système de manipulation de fichiers de Windows 8,3 peut parfois être utilisée pour contourner les filtres de téléchargement fichiers

Exemples d'utilisation:

• file.phtml traité comme un script PHP
• FICHIER ~ 1.PHT est servi, mais pas traitée par le gestionnaire PHP ISAPI
• shell.phPWND peuvent être téléchargées
• SHELL ~ 1.php sera éltendu et retourné par le SHELL OS, puis traité par le gestionnaire PHP ISAPI

Les tests boîte blanche contre les extensions de fichiers permettent de vérifier les configurations de serveur (s) web / serveur d'application (s) participant à l'architecture des applications Web, et de vérifier la façon dont ils sont chargés de servir les extensions de fichiers différentes.

Si l'application Web repose sur un équilibrage de charge, une infrastructure hétérogène, cela permet de déterminer si ça peut induire un comportement différent.

Les scanners de vulnérabilités, comme Nessus et Nikto vérifient l'existence des répertoires web bien connus. Ils peuvent ainsi permettre de télécharger la structure du site web, ce qui est utile lorsque vous essayez de déterminer la configuration des répertoires Web et comment les extensions de fichiers individuels sont servies. D'autres outils peuvent être utilisés à cette fin :

• wget - http://www.gnu.org/software/wget
• curl - http://curl.haxx.se
• google pour “web mirroring tools “.