Défaillance dans la restriction des accès à une URL

1. PrincipeMain en arriere fleche dessinee 318 51824

Cette faille permet à un utilisateur d'accéder à des fonctionnalités de l'application, voire des fichiers et répertoires du serveur HTTP sans y être habilité.

L'attaque par traversée de répertoires permet d'accéder à des fichiers du serveur HTTP notamment ceux contenant les clés privées de chiffrement. Les applications vulnérables ouvrent des fichiers dont le nom est donné en paramètre de la requête HTTP.

Une autre attaque consiste à deviner l'existence de fichiers ou de répertoires. En effet de nombreux outils disposent d'une interface d'administration dont l'adresse d'accès est du type « http://www.site_vulnerable.fr/admin/admin.php ». Dans ce cas même si l'utilisateur malintentionné n'y a pas accès au travers de l'application, il peut saisir directement l'adresse pour l'ouvrir. Les applications vulnérables ne demandent pas de s'authentifier avant de pouvoir l'utiliser, la seule protection étant qu'aucun lien n'est mis à disposition pour y accéder, ce qui n'est pas suffisant.

Une attaque équivalente consiste à ne pas spécifier de nom de fichier dans l'adresse, par exemple « http://www.site_vulnerable.fr/admin/ ». Les serveurs HTTP vulnérables afficheront le contenu du répertoire.

2. Exemples d'attaque

L'exemple suivant montre une portion de code vulnérable à l'attaque par traversée de chemin. L'application est construite pour inclure du texte en fonction de la langue du navigateur. Dans ce cas la langue est donnée en paramètre de la requête HTTP, la commande PHP « includelang_nom_fichier.php » permet d‘inclure le contenu du fichier concerné.

Figure 25 - Script PHP vulnérable à l'attaque par traversée de chemin

Sélectionnez

<?php 
$language="entete-en"; 
if (isset($_GET['lang'])) { 
    $language=$_GET['lang']; 
} 
include ("/usr/local/webapp/template/" . $language . ".php") 
?>

Si l'attaquant envoie la requête avec le paramètre « lang=../../../../etc/passwd », il aura accès au fichier des mots de passe du système et tentera de se connecter au serveur HTTP avec un des comptes ainsi trouvés.

Dans cet exemple l'attaque par traversée de chemin est possible à cause de la faille Référence directe non sécurisée à un objet (voir paragraphe III.E).

3. Parade et bonnes pratiques

Pour se protéger des défaillances dans la restriction des accès à une URL, il ne faut pas autoriser les caractères douteux tels que « / » et « \ ».

Pour se prémunir des attaques par traversée de chemin, il faut établir une liste de fichiers utilisables et refuser tout autre fichier. La correction à apporter à l'exemple ci-dessus est la suivante.

Figure 26 - Script PHP non vulnérable à l'attaque par traversée de chemin

Sélectionnez

<?php 
$languages=array("entete-en","entete-fr","entete-es"); 
$language=$languages[1]; 
if (isset($_GET['lang'])) { 
    $tmp=$_GET['lang']; 
    if (array_search($tmp, $languages)) { 
        $language=$tmp; 
    } 
} 
include ("/usr/local/webapp/template/" . $language . ".php") 
?>

Tous les répertoires doivent contenir un fichier index.html, ce qui évite de pouvoir accéder au répertoire lui-même. De plus, les serveurs HTTP doivent être configurés pour ne pas permettre l'affichage du contenu des répertoires.

Pour éviter les accès à des fonctionnalités sans autorisation, ces dernières doivent être protégées en vérifiant que l'utilisateur a le droit de les utiliser. Ne pas afficher de lien pour y accéder n'est pas une protection suffisante.