Test des vulnérabilités d'injection SQL

Les attaques par injection SQL représentent des risques énormes pour les applications Web qui dépendent d'un moteur de base de données pour générer du contenu dynamique. Dans ce type d'attaque, les pirates informatiques manipulent une application Web dans le but d'injecter leurs propres commandes SQL dans celles émises par la base de données. Pour un exemple, voir l'article Attaques par injection SQL sur des bases de données. Dans cet article, nous examinons différentes manières de tester vos applications Web afin de déterminer si elles sont vulnérables aux attaques par injection SQL.

Analyse automatisée par injection SQL

Une possibilité consiste à utiliser un scanner automatisé de vulnérabilités d'applications Web, tel que WebInspect de HP, AppScan d'IBM ou Hailstorm de Cenzic. Ces outils offrent tous des moyens simples et automatisés d’analyser vos applications Web à la recherche de vulnérabilités potentielles par injection SQL. Cependant, ils coûtent assez cher et peuvent atteindre 25 000 dollars par siège.

Tests d'injection SQL manuels

Qu'est-ce qu'un mauvais développeur d'applications à faire? Vous pouvez en fait exécuter des tests de base pour évaluer vos vulnérabilités d’injection SQL dans vos applications Web à l’aide d’un navigateur Web. Tout d’abord, un mot d’attention: les tests que nous décrivons ne cherchent que des défauts fondamentaux de l’injection SQL. Ils ne détectent pas les techniques avancées et sont un peu fastidieux à utiliser. Si vous pouvez vous le permettre, utilisez un scanner automatisé. Cependant, si vous ne pouvez pas gérer ce prix, le test manuel est une excellente première étape.Le moyen le plus simple de déterminer si une application est vulnérable consiste à expérimenter des attaques par injection inoffensives qui ne feront pas de mal à votre base de données si elles réussissent, mais qui vous fourniront la preuve que vous devez corriger un problème. Par exemple, supposons que vous disposiez d'une application Web simple qui recherche un individu dans une base de données et fournit les informations de contact en conséquence. Cette page peut utiliser le format d'URL suivant:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Nous pouvons supposer que cette page effectue une recherche dans la base de données en utilisant une requête semblable à la suivante:

SELECT téléphone

FROM répertoire

WHERE lastname = 'chapple' et prenom = 'mike'

Expérimentons un peu avec cela. Avec notre hypothèse ci-dessus, nous pouvons apporter un simple changement à l'URL qui teste les attaques par injection SQL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

Si l'application Web n'a pas été correctement protégée contre l'injection SQL, elle branche simplement ce faux nom dans l'instruction SQL qu'il exécute sur la base de données, ce qui entraîne:

SELECT téléphone

FROM répertoire

WHERE lastname = 'chapple' et prenom = 'mike'

ET (sélectionnez le nombre (*) parmi les faux)> 0

OU '1' = '1'

Vous remarquerez que la syntaxe ci-dessus est légèrement différente de celle de l'URL d'origine. Nous avons pris la liberté de convertir la variable encodée en URL pour ses équivalents ASCII afin de faciliter le suivi de l'exemple. Par exemple,% 3d est le codage d'URL pour le caractère '='. Nous avons également ajouté des sauts de ligne à des fins similaires.

Évaluation des résultats

Le test intervient lorsque vous essayez de charger la page Web avec l'URL indiquée ci-dessus. Si l'application Web se comporte bien, elle supprimera les guillemets simples de l'entrée avant de transmettre la requête à la base de données. Cela se traduira simplement par une recherche étrange pour quelqu'un avec un prénom qui comprend un tas de SQL. Vous verrez un message d'erreur de l'application similaire à celui ci-dessous:

Erreur: Aucun utilisateur trouvé avec le nom mike + AND + (select + count (*) + from + faux) +% 3e0 + OR + 1% 3d1

Chapple!

D'autre part, si l'application est vulnérable à l'injection SQL, elle transmettra l'instruction directement à la base de données, ce qui offre l'une des deux possibilités. Premièrement, si des messages d'erreur détaillés sont activés sur votre serveur (ce que vous ne devriez pas faire), vous verrez quelque chose comme ceci:

Erreur '80040e37' du fournisseur Microsoft OLE DB pour les pilotes ODBC

Microsoft Pilote ODBC SQL Server SQL Server Nom d'objet non valide 'Fake'.

/directory.asp, ligne 13

D'autre part, si votre serveur Web n'affiche pas de messages d'erreur détaillés, vous obtiendrez une erreur plus générique, telle que:

Erreur Interne du ServeurLe serveur a rencontré une erreur interne ou une mauvaise configuration et n'a pas pu traiter votre demande.

Veuillez contacter l'administrateur du serveur pour l'informer de l'heure à laquelle l'erreur s'est produite et de tout ce que vous avez pu faire qui pourrait être à l'origine de l'erreur.

Plus d'informations sur cette erreur peuvent être disponibles dans le journal des erreurs du serveur.

Si vous recevez l'une des deux erreurs ci-dessus, votre application est vulnérable aux attaques par injection SQL. Voici quelques étapes à suivre pour protéger vos applications contre les attaques par injection SQL:

• Implémentez la vérification des paramètres sur toutes les applications. Par exemple, si vous demandez à quelqu'un de saisir un numéro de client, assurez-vous que la saisie est numérique avant d'exécuter la requête.
• Limitez les autorisations du compte qui exécute les requêtes SQL. La règle du moindre privilège s'applique. Si le compte utilisé pour exécuter la requête n'a pas la permission de l'exécuter, cela n'aboutira pas.
• Utilisez des procédures stockées (ou des techniques similaires) pour empêcher les utilisateurs d’interagir directement avec le code SQL.