Les principales failles de sécurité des applications web actuelles, telles que recensées par l'OWASP: principes, parades et bonnes pratiques de développement

4. FAILLES DE SÉCURITÉ

4.1 Injection

4.1.1 Principe

L'attaque par injection est évaluée par l'OWASP comme étant la plus risquée, car la faille est assez répandue, il est facile de l'exploiter et l'impact peut être très important. Cela va de la simple récupération de données à la prise totale de contrôle du serveur. La victime de l'attaque est un des composants technique de l'application Web.

M. Contensin [8] explique que pour réaliser une attaque de ce type, il faut injecter dans les zones de saisie classiques présentées à l'utilisateur du code malicieux. Ces données seront interprétées comme des instructions par un des composants de l'application Web. Les champs de formulaires peuvent être protégés par Javascript pour vérifier que les valeurs saisies correspondent à ce qui est attendu. Cependant, J. Scambray, V. Liu et C. Sima [9] démontrent qu'il est possible d'outrepasser ces vérifications en faisant appel à un serveur proxy personnel, par exemple, qui permettra d'intercepter les requêtes pour les modifier et envoyer le code malicieux. La difficulté de l'attaque réside finalement dans la détection des technologies utilisées pour formuler le code d'attaque adéquat. Cependant, la plupart des applications Web de gestion de contenu présentes sur le Web sont basées sur des projets Open Source. H. Dwivedi, A. Stamos, Z. Lackey et R. Cannings  [10] montrent qu'il est alors facile d'identifier les technologies employées en parcourant le code source mis à disposition. De plus, il existe des outils d'injection automatique disponibles sur le Web, rendant le risque plus élevé. L'exploitation de la faille devient automatisable.

4.1.2 Exemples d'attaque

L'attaque par injection SQL consiste à injecter du code SQL qui sera interprété par le moteur de base de données. Le code malicieux le plus répandu est d'ajouter une instruction pour faire en sorte que la requête sous-jacente soit toujours positive. Cela permet par exemple d'usurper une identité pour se connecter à une application Web, de rendre l'application inutilisable ou de supprimer toutes les données de la table visée, voire même de la base de données complète. L'exemple suivant va interroger une table qui contient la liste des cartes bancaires enregistrées dans la base de données de l'application Web d'un site marchand. Le script de création de cette table est le suivant :

CREATE TABLE IF NOT EXISTS `comptes` (  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'identifiant',  `nom` varchar(30) NOT NULL COMMENT 'nom d''utilisateur',  `motdepasse` varchar(41) NOT NULL,  `typecarte` varchar(30) NOT NULL COMMENT 'type de carte',  `numerocarte` varchar(30) NOT NULL COMMENT 'numéro de carte',  PRIMARY KEY (`id`),  UNIQUE KEY `nom` (`nom`)) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ;

Figure 5 - Script SQL de création de la table « comptes »

Pour afficher le numéro de carte bancaire, l'utilisateur doit s'authentifier. La requête SQL suivante permet de vérifier que le couple utilisateur « user4 »/mot de passe du compte « eng111 » est correct et si tel est le cas renvoie le numéro de carte bancaire :

SELECT `numerocarte` 
FROM `comptes` 
WHERE `nom` = 'user4'
AND `motdepasse` = PASSWORD( 'eng111' )

Figure 6 - Requête SQL pour l'authentification et affichage du numéro de carte

Le script PHP pour exploiter cette requête de façon dynamique avec les informations fournies par l'utilisateur est le suivant :

<?php //connexion a la base de donneesmysql_connect('localhost', 'root', '');mysql_select_db('eng111');//recuperation des parametres$nom = $_GET['nom'];$motdepasse = $_GET['motdepasse'];//generation de la requete$requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom' AND motdepasse = PASSWORD( '$motdepasse' )";//execution de la requete$reponse = mysql_query($requeteSQL);$resultat = mysql_fetch_assoc($reponse); //affichage du resultatecho $resultat['numerocarte'];?>

Figure 7 - Script PHP pour l'authentification et l'affichage du numéro de carte

En remplissant le formulaire avec la valeur « ' OR 1=1 -- ' » pour le champ « nom » et n'importe quelle valeur pour le mot de passe, la requête qui sera envoyée à la base de données devient :

SELECT numerocarte FROM comptes WHERE nom = '' OR 1=1 -- '' AND motdepasse = PASSWORD( 'x' )

Figure 8 - Requête SQL incluant du code frauduleux d'injection

Ainsi la condition 1=1 est toujours vérifiée et le reste de la commande est mis en commentaire grâce à la chaîne de caractères « -- ». Cela permet donc de récupérer aléatoirement un numéro de carte.

L'attaque par injection de XPath suit le même principe que pour SQL [11]. En effet, XPatch est un langage de requête pour gérer les données stockées au format XML, comme le fait SQL pour les bases de données relationnelles. XPath et Xquery, dont XPath est un sous-ensemble, souffrent donc des mêmes vulnérabilités face à l'injection de code malicieux.

L'attaque par injection LDAP permet d'accéder à des informations privées qui sont enregistrées dans l'annuaire d'entreprise. En modifiant le comportement du filtrage dans la requête LDAP qui sera générée, il est possible de récupérer la liste exhaustive des adresses de courrier électronique d'une entreprise pour les saturer de spam par exemple.

L'attaque par injection de commandes est surtout principalement possible sur les scripts CGI écrits en Perl, PHP et Shell. Il est possible de prendre le contrôle du serveur. Il faut pour cela faire en sorte que la commande initiale soit exécutée sans problème et ajouter des commandes du système d'exploitation du serveur qui seront exécutées par le serveur.

L'attaque par traversée de répertoire permet d'accéder à des fichiers présents sur le serveur. Les fichiers cibles privilégiés étant ceux contenant des informations de sécurité comme le fichier des mots de passe ou les fichiers contenant les clés privées de chiffrement pour SSL par exemple. Cette attaque est rendue possible si l'application Web inclue du contenu de fichier en passant l'adresse de ce fichier en paramètres de la requête.

Les attaques XXE (XML eXternal Entity) sont un dérivé des attaques par traversée de répertoire. Les conséquences vis-à-vis des fichiers présents sur les serveurs sont donc les mêmes. Ce type d'attaque est basé sur la fonctionnalité de XML « entités externes ». Les entités sont des substituts pour des séquences d'information. Elles sont équivalentes aux variables dans les langages de programmation. Les entités externes permettent de déclarer des documents dont le contenu sera affiché lors de l'utilisation de l'entité. Si l'entité pointe sur un fichier existant sur le serveur, son contenu pourra être divulgué à l'attaquant. Cette fonctionnalité peut être exploitée en plaçant un fichier XML au format RSS sur un site et de l'intégrer à un agrégateur en ligne. Si ce dernier est vulnérable, il sera alors possible de voir le contenu des fichiers demandés par l'attaquant.