Anatomie d’une attaque par injection

se
produire n’importe où, dès lors qu’un
utilisateur soumet des données destinées
à  être exploitées dans votre application,
que ce soit à  partir d’une zone
de texte d’un formulaire Web ou par le
biais d’une chaîne de requête de navigateur
supposée non modifiable.
Un attaquant peut se servir d’une
page de connexion, d’une page de recherche ou de pratiquement
n’importe quelle page qui accepte directement ou
indirectement des saisies utilisateur. Un intrus potentiel peut
alors lancer son attaque à  partir de n’importe quel champ de
saisie d’application qui ne filtre pas correctement les saisies
utilisateur avant de les envoyer à  SQL Server. Je pense que la
meilleure façon d’illustrer ce type d’attaque consiste à 
prendre un exemple. Pour ce faire, j’ai choisi une page de
connexion simple comme point d’attaque.


Vous pouvez télécharger l’exemple
de projet ASP.NET à  l’adresse http://
www.itpro.fr (Club abonnés), copier
les fichiers sur le site Web par défaut de
votre machine de développement et
suivre la procédure. Notez que lorsque
vous copiez un projet ASP.NET sur un
serveur Web après avoir placé le répertoire
de l’application sous le site Web
par défaut, vous devez ouvrir le
Gestionnaire des services Internet
(Microsoft IIS Manager) et modifier le
statut du répertoire en Application. Au
lieu de télécharger le code à  partir
d’Internet, vous pouvez aussi créer un
nouveau projet complet. Pour aboutir
à  la page de connexion illustrée sur la
figure 1, utilisez Visual Studio .NET afin
de créer un nouveau projet ASP.NET.
(J’ai utilisé Visual Basic .NET comme
langage de mise en oeuvre.) Effectuez
ensuite la procédure suivante :

• Faites glisser quatre contrôles Label (libellé) sur la page et
  modifiez le texte par défaut pour chacun d’eux comme
  suit :
  • Modifiez la propriété de texte du premier libellé en Enter
    You User Name and Password (Saisissez vos nom d’utilisateur
    et mot de passe) et utilisez une police de taille 14 avec
    le style Gras.

  • Modifiez la propriété de texte du deuxième libellé en
    Name: (Nom).

  • Modifiez la propriété de texte du troisième libellé en
    Password: (Mot de passe).

  • Modifiez la propriété de texte du quatrième libellé en
    Result: (Résultat).
• Changez l’ID du contrôle Label qui affiche le résultat de la
  connexion de Label4 en lblResult.

• Ajoutez deux zones de texte et effacez leur texte par défaut.
• Ajoutez un bouton, modifiez son texte en Login (Connexion),
  puis double-cliquez sur l’affichage pour ouvrir le fichier
  de code sous-jacent pour votre page par défaut.
  Dans cet exemple, utilisez le code sous-jacent ASP.NET du
  listing 1.

La chaîne de connexion du code du listing 1 connecte
une instance locale de SQL Server, laquelle contient la base
de données exemple Northwind, au compte sa. Vous devez
changer le mot de passe sa afin qu’il corresponde à  celui que
vous utilisez sur le système local. Ensuite, vous devez créer la
table employée dans cet exemple au niveau de la base de
données. Pour cela, vous pouvez ajouter une table UserInj à 
votre base de données Northwind à  l’aide de l’instruction TSQL
suivante :
< br>
CREATE TABLE UserInj(UserId
varchar(50), password
varchar(50))

Assurez-vous de saisir au moins un utilisateur dans cette
table. Vous pouvez employer n’importe quels nom d’utilisateur
et mot de passe. La clé de la réussite d’une injection de
code SQL réside dans la possibilité d’exécuter l’application et
de se connecter sans utiliser d’informations
d’identification valides. Dans cet exemple, j’ai
lancé mon attaque à  partir d’un formulaire
Web. Comme l’illustre la figure 1, même si j’ai
saisi un ensemble d’informations d’identification
non valides, la page indique la réussite de
la connexion en accueillant l’utilisateur intitulé
Bill.

Concernant la zone de texte Password
illustrée à  la figure 1, j’ai intentionnellement employé le mot
de passe de la capture d’écran afin de montrer que j’ai saisi
une chaîne qui, de toute évidence, ne peut pas constituer un
mot de passe. Cette attaque par injection de code SQL toute
simple démontre bien qu’en injectant des commandes, des
intrus peuvent faire en sorte que votre application fasse l’impasse
sur de nombreux aspects de sa logique, tels que la validation
des mots de passe. J’ai lancé l’attaque à  partir de la
chaîne saisie comme nom d’utilisateur :

sadf ‘ OR 1 = 1 —

Cette chaîne utilise deux caractères pour manipuler le
SQL dynamique au cours du processus de connexion : un
guillemet simple et deux tirets. La chaîne commence par les
caractères invalides sadf afin de faire en sorte que j’ai
quelque chose à  utiliser dans l’instruction SQL de l’application.
Ainsi, cette dernière ne peut pas renvoyer une erreur.
Le caractère suivant lance l’attaque sur la requête SQL au niveau
du bloc A du listing 1. Le guillemet simple, lorsqu’il est
incorporé dans une requête dynamique, ferme la valeur de
chaîne faisant partie de la clause WHERE définie dans la requête
SELECT du bloc A. La chaîne insérée ajoute ensuite
une instruction conditionnelle (OR) à  la commande SQL, qui
est toujours vraie (1=1). Enfin, la chaîne ajoute deux tirets
afin de placer en commentaire le reste de la commande
d’origine. Le résultat est la requête SQL piratée suivante :

SELECT * FROM UserInj WHERE
userid=’sadf’ OR 1 = 1 –‘ AND
password=’password’



Comme cette requête est partiellement placée en commentaire,
l’application ignore le mot de passe. Le code identifie
à  tort l’utilisateur comme étant celui retourné figurant
en haut de la liste des utilisateurs. Ainsi, comme l’illustre la figure
1, l’application considère l’attaquant comme authentifié,
bien que le nom d’utilisateur et le mot de passe ne soient
pas valides. Naturellement, ce type d’attaque peut être plus
complexe et occasionner plus de dommages que la chaîne
toute simple employée ici. Par exemple, vous pourriez saisir
la commande suivante :

sadf ‘ OR 1 = 1 ; DROP TABLE
USERINJ —

laquelle démontre plus clairement la puissance destructrice
potentielle des attaques par injection de code SQL. Non
seulement ce code contourne l’instruction de connexion,
mais il supprime également une table, présentement la table
utilisateur. Parmi les autres actions réalisables par un intrus, citons la création d’un nouvel utilisateur dans la table de
connexion, l’exécution de requêtes sur d’autres tables
connues ou encore l’utilisation de requêtes de gestion SQL
pour localiser et définir d’autres tables. Avec les autorisations
d’utilisateur appropriées, un attaquant peut se servir de l’injection
de code SQL pour accéder à  l’intégralité de votre système.

En tant qu’administrateur de base de données (DBA),
vos moyens de défense contre ce type d’attaque sont limités.
L’injection de code SQL exploite deux zones de vulnérabilité :
le champ de saisie de données utilisé comme point d’entrée
par l’attaquant et pour exécuter la commande d’injection
d’une part et, d’autre part, les autorisations que vous définissez
au niveau de la base de données. En sécurisant ces
deux aspects, vous pouvez limiter la portée de l’attaque. Si
vous sécurisez un seul de ces aspects, vous courez le risque
qu’un intrus accède à  l’ensemble des données privées de
votre organisation, les utilise de manière frauduleuse ou les
détruisent. Pour garantir une protection totale, vous devez
ajouter des couches de défense qui limitent la saisie acceptée
par votre application et se servent des autorisations de base
de données appropriées. Ainsi, même en cas de défaillance
d’une partie de votre défense, une autre couche continuera
de protéger vos données.