SQL Parser XML Xquery : Approche de détection des injections SQL

SQL Parser XML Xquery : Approche de détection des injections SQL Ramahefy T.R. 1, Rakotomiraho S. 2, Rabeherimanana L. 3 Laboratoire de Recherche Systèmes Embarqués, Instrumentation et Modélisation des Systèmes et Dispositifs Electroniques (LR-SE-I-MSDE) Ecole Doctorale en Sciences et Techniques de l Ingénierie et de l Innovation (ED-STII) Ecole Supérieure Polytechnique - Université d Antananarivo BP 1500 - Antananarivo 101 Madagascar 1 ramahefy@yahoo.fr rakmiraho@yahoo.fr 2 lilirabe@voila.fr 3 Résumé Cet article présente une proposition de méthode de détection des injections SQL qui s'est basée sur l'approche SQL Parser XML- XQuery. L approche utilise la technique d'analyse lexicale et l'analyse syntaxique pour contrôler les entrées avant d'exécuter la requête correspondante dans la base de données. Le processus consiste à construire un profil de comportement de l'application dans deux fichiers XML pendant la phase d apprentissage et pendant la phase de détection. Le résultat de ces analyses permet d'extraire et d'indiquer la requête qui s'écarte du comportement normal via le préprocesseur XQuery. Mots-clés: Injection SQL, SQL parser, vulnérabilité web, analyse lexicale, analyse syntaxique Abstract This article presents a proposal method of detecting SQL injection which is based on SQL Parser XML - XQuery approach. This approach uses lexical and parsing analysis to control data inputs before executing the corresponding query in the database. The process involves building application behavior profile in two XML files during the learning and detection phase. The result of these analyses allowed extracting and specifying the query that deviates from the normal behavior via XQuery preprocessor. Keywords: SQL injection, SQL parser, web vulnerability, lexical analysis, syntactic analysis 1- Introduction L application web et son infrastructure utilisent des technologies diverses. La maturité du marché de sécurité réseau et les nombreuses fonctions d'entrées utilisées à travers les interfaces web font que l'application est un objectif populaire pour l'attaque. L'injection SQL est l'une des failles les plus critiques pour une application utilisant une base de données SQL [1] et fait la Une des presses mondiales ces dernières 1

années. Les injections SQL commencent par entrer des données suspicieuses ou par utiliser des fragments de codes à travers les applications web. Cette approche nous permet de les détecter facilement. Il est ainsi intéressant de voir successivement l approche de détection de l injection SQL, le processus de la détection, la simulation et le résultat de l'approche, son évaluation et quelques recommandations. 2- Approche de détection de l injection SQL En général, l approche de détection des injections SQL se fait en deux étapes très distinctes [2] la phase de formation ou phase d apprentissage et la phase de détection. La figure 01 suivante montre le schéma synoptique de l approche PHP Parser XML- XQuery Requête Analyseur Lexical Syntaxique Compilation XML Fichier référence Fichier requête Figure 01 : Schéma synoptique du processus de l approche 2.1 Phase d apprentissage Requête XML Processeur XQuery Analyse résultat La phase d apprentissage consiste à étudier le comportement normal de l application depuis que les données sont entrées dans l interface web jusqu à ce que les requêtes créées soient envoyées dans la base de données. La source d obtention des traces est soit par le journal de la base de données soit par SQL Parser en faisant une simulation à vide de la requête que le développeur veut envoyer dans la base de données. Autrement dit, le but étant d encoder efficacement les requêtes afin d extraire leurs caractéristiques utiles et d avoir l empreinte de l application dans un fichier XML. En appliquant les règles d associations sur le fichier XML, le fichier obtenu contient ainsi une liste des requêtes légitimes classées susceptibles à l attaque d injection SQL. 2.2 Phase de détection La phase de détection considère à la fois la détection des anomalies et la détection d abus. La phase précédente a montré comment les requêtes bénignes sont collectées et saisies dans un fichier XML pour créer une règle sur une requête. Lors de l utilisation de l application par l utilisateur, chaque requête sensible est testée sur cette empreinte de l application et chaque règle qui dépasse le minimum de soutien et la confiance ne serait pas envoyée dans la base 2

de données et ne sera pas exécutée. Dans une application typique de base, l interface demande à l utilisateur de fournir les données d entrées nécessaires pour les clauses à partir de WHERE de la requête et la clause FROM reste statique au moment de l exécution. Toute modification à partir de la clause WHERE par des attaquants qui ne peut pas être tirée à partir du profil des règles sera considérée comme une injection SQL. 3. Processus de détection Plusieurs étapes sont suivies pour le processus de détection allant de la recherche des requêtes sensibles, de la décomposition de la requête par SQL Parser, de la création des fichiers XML jusqu à l extraction des fichiers par XQuery. Ceci est récapitulé par la figure 02. Oui Interface web Données entrées Requête SQL Sensible SQL Parser Création fichier XML Vérifier séquence Séquence existe Matrice Fichier XML/profil Figure 02 : Organigramme de détection a- Recherche des requêtes sensibles La première étape à faire pour commencer le processus de détection des injections SQL est de spécifier toutes les requêtes sensibles. Souvent les requêtes dans une authentification, les requêtes utilisées dans les affichages filtrés sont considérées comme requêtes sensibles et sont exposées aux attaques. C est le travail des développeurs de les déterminer avant que les attaqueurs les trouvent pour mettre le site hors de la vulnérabilité SQL. b- SQL Parser Après avoir trouvé les requêtes sensibles, l étape suivante consiste à les décomposer en plusieurs sections en fonction de la commande «SELECT, UPDATE, DELETE, SHOW, ALTER», du nom de la table, des noms des opérateurs ainsi que les valeurs des champs. Le SQL Parser n est autre qu un analyseur lexical et syntaxique des requêtes SQL basés essentiellement sur des automates. Un arbre de syntaxe abstrait est ainsi formé comme le montre la figure 03. Effacer fichiers XML et XQUERY Non Revérifier requête Non Oui Ajouter séquence Autoriser envoi requête Base de données Bloquer requête Alerter injection 3

Figure 03 : Arbre syntaxique d une requête par SQL Parser principale FLWOR (For-Let-Where-Order- Return). XQuery arrive à gérer un calcul complexe à partir des informations extraites et à la reconstruire en un fichier XML [3]. Le but de notre approche est d exploiter le fragment de code ainsi que le contenu des nœuds via le processeur XQuery. Chaque requête sensible aura ainsi son propre fichier XQuery pour faire cette interrogation 3. Résultat de l approche c- Création des fichiers XML Le XML (Extensible Markup Language) est utilisé ici pour stocker et traiter les données issues de la requête décomposée. Le fichier XML de référence ou empreinte de l application est le premier fichier à créer. Pour optimiser la recherche du processeur XQuery, l ajout d identificateur id dans chaque séquence de balise est nécessaire. Il ne faut pas oublier qu il existe aussi des références d entités de caractères spécifiques pour XML. Le second fichier XML est créé lors de la manipulation de l interface de l application. d- XQuery XQuery est un langage conçu pour l interrogation des arbres dans un fichier XML. Il utilise les expressions XPath pour faire la recherche au niveau de la position dans un arbre à travers son expression 4 L approche a été testée avec plusieurs types de commande. La commande SELECT est donnée dans la figure 04. SELECT nom, email FROM users WHERE blocked=0 username='rakoto' and password ='Test1234' Figure 04 : Exemple de requête à analyser 3.1 Décomposition d une requête par SQL Parser PHP est le langage utilisé pour décomposer la requête SQL de la figure 04. Notre script PHP analyse la requête SQL en utilisant ses librairies de fonction surtout les «regex» ou «expressions régulières». L analyse se limite ainsi à une décomposition de la

grammaire SQL. L arbre syntaxique obtenu est ainsi représenté par la figure 05 suivante. MADA-ETI, ISSN 2220-0673, Vol.1, 2015, www.madarevues.gov.mg SELECT nom, Email FROM users WHERE blocked=0 and username= Rakoto and passeword= Test1234 SELECT List select FROM List table Where List-where commande colref commande table commande colref operator const nom Email users username Rakoto Figure 05 : Arbre syntaxique de la requête SELECT d un login L affichage à la sortie est un tableau multidimensionnel dont les clés et les valeurs sont bien structurées et exploitées comme indique la figure 06. 5 Figure 06 : Variable array du SQL Parser pour une requête SELECT 3.2 Script XML Le fichier XML de référence a été créé pendant la phase d apprentissage. Le but de la création du fichier XML est de généraliser les requêtes, c est-à-dire d avoir une requête généralisée dans les séquences de chaque nœud dont la valeur à l intérieur est globale. La valeur d un champ est alors testée et remplacée par string si c est une chaîne de caractère, number si c est du nombre ainsi de suite. L autre fichier XML est créé de la même manière mais la différence c est que la première est considérée comme une matrice pour l interrogation du second fichier. La balise <querys> comporte l identification id de la requête. Si la requête n est pas une attaque alors le contenu de ce dernier fichier devrait être le même que celui de la séquence dans le fichier de la phase de formation. Si la requête est une attaque, la balise <querys> comporte

toujours la même identification mais c est la séquence des nœuds qui n est pas pareille à la séquence stockée dans le fichier matrice c est pourquoi elle est considérée comme une attaque. La figure 07 est un exemple de fichier XML de référence créé lors de la phase d apprentissage. <modelquery> <querys id="1"> <command>update</command> <table>employee</table> <command>set</command> <colref>salary</colref> <const>number</const> </querys> <querys id="3"> <command>select</command> <colref>nom</colref> <colref>email</colref> <command>from</command> <table>user</table> <command>where</command> <colref>blocked</colref> <const>const</const> <colref>user</colref> <colref>password</colref> </querys> </modelquery> Figure 07: Fichier XML de référence pendant la phase d apprentissage Lors de la phase de détection, toutes les requêtes sensibles passent toujours par SQL Parser dans le but de pouvoir les transformer en fichier XML. La création du fichier XML lors de la phase de détection est le même principe que celui de la phase d apprentissage. Lorsqu un utilisateur 6 Rakoto/Test1234 veut s authentifier la requête correspondante est donnée par la figure 04. Quand un attaquant entre «attacker or 1= 1 --» dans le champ identifiant en remplissant ou non dans la zone de password, la requête correspondante est donnée par la figure 08 et le fichier XML créée est illustré par la figure 09. SELECT nom, email FROM users WHERE blocked='0' AND user ='attacker' or 1=1 -- ' AND paswd = '' Figure 08: Requête d authentification avec injection SQL Comme or 1=1 retourne toujours vrai alors si cette requête n est pas passée dans notre détecteur d injection SQL avant d être exécutée, alors l attaqueur arrivera à contrôler l administration du site Web. <querys id="3"> <command>select</command> <colref>nom</colref> <colref>email</colref> <command>from</command> <table>user</table> <command>where</command> <colref>blocked</colref> <const>const</const> <colref>user</colref> <colref>password</colref> </querys> <querys id="3"> <command>select</command> <colref>nom</colref> <colref>email</colref> <command>from</command> <table>user</table> <command>where</command> <colref>blocked</colref> <const>const</const> <colref>user</colref> <operator>or</operator> <const>1</const> <const>number</const> <colref>==' AND password='test1234'</colref> /

a- Requête normale b- Requête anormale Figure 09 : Fichier XML généré pour une requête normale et anormale 3.3 Script principal en PHP La fonction checksqlia () est le cœur de notre approche développée en PHP. Toutes les requêtes sensibles appellent cette fonction avant d être exécutées à la BD. checksqlia () est une fonction qui rassemble toutes les étapes de cette approche. Chaque étape se présente sous forme de «classe» composée de plusieurs «méthodes» ou «fonctions membres». Le script aura successivement une classe pour SQL Parser [4], une classe pour la création des fichiers XML, pour la création du fichier XQuery. Le code de lancement de la commande shell pour XQuery est aussi présent dans cette fonction checksqlia(). La fonction checksqlia () de la figure 10 retourne ainsi une valeur booléenne «false» pour détecter cette attaque. 7 Figure 10 : Programme principal de l approche 3.4 Script XQuery Le code XQuery utilisé pour extraire les informations dans les fichiers matrices XML est donné par la figure 11. La fonction «détection SQLIA» en XQuery est créée pour faire cette interrogation dans le fichier XML de référence. En réalité ce fichier fait une comparaison étroite des nœuds des deux fichiers XML et retourne sous une variable booléenne la réponse de cette comparaison. Figure 11 : Exemple de programme XQuery pour l approche En lançant ce programme, la seconde requête (fig 09b) est identifiée comme une SQLIA. Cette requête n est pas envoyée dans la BD puisque la variable retournée par la fonction check SQLIA est false. Une autre fonction est créée pour le reporting afin d alerter l administrateur du site Web en envoyant un mail ou des alertes de SQLIA pour que ce dernier prenne des décisions y afférentes.

4- Evaluation et recommandation Cette approche ne génère pas de faux négatifs et en passant par un bon apprentissage, elle ne génère pas non plus de faux positifs. La création des deux fichiers.xml et.xquery pourrait charger le serveur, c est la raison pour laquelle il est toujours nécessaire de supprimer les fichiers issus des requêtes bénignes. L exécution de l extension du XQuery n est pas automatique sur la version actuelle de PHP. En réalité pour ajouter une extension sur la version 5.3, l utilisation de la fonction dl_() nécessite quelque paramétrage d entrée [5]. Pour notre cas, nous avons choisi Zorba pour simuler cette approche. Zorba est un simulateur de code XQuery qui contient des API utilisables en java, PHP et Perl ainsi que les autres plateformes SQL. Alors nous avons installé Zorba et lancé la commande «exec()» pour faire fonctionner notre simulation 5- Conclusion Les injections permettent d avoir accès aux données, de les modifier voire de les supprimer, d usurper le compte d un utilisateur, d accéder à la structure de la base, de contourner les règles de gestion, ou encore obtenir certaines informations concernant le serveur. Prendre en compte 8 ces risques potentiels apportés par les injections SQL a conduit à concevoir une approche pour les détecter. L approche SQL Parser XML-XQuery s appuie sur la technique d analyse lexicale et syntaxique. Les deux phases principaux pour cette approche sont la phase d apprentissage qui nous a permis d avoir un fichier XML de référence et la phase de détection qui nous a transformé la requête «chaude» en un autre fichier XML. Pendant la phase de détection, l analyseur de requête XQuery fait une interrogation du dernier fichier XML au fichier de référence. Une requête est considérée comme SQLIA si le résultat de la recherche retourne false. L analyse de cette approche nous a permis de dégager une piste de travail répondant à nos objectifs d avoir une approche effective et efficace de detection des injections SQL en exploitant l analyse lexicale et l analyse sémantique. Notre prochain travail consistera à l exploitation de l analyse sémantique qui n est autre que la partie complémentaire. 6. Références [1]- «OWASP TOP 10-2013» OWASP, The open web application Security Projecthttps://www.owasp.org/index. php/top_10_2013, Mai 2013

[2]- William G.J., Halfond and Orso A.,«Combining Static Analysis and Runtime Monitoring to Counter SQL-Injection Attacks», College of Computing Georgia Institute of Technology,Mai 2005 http://www.cc.gatech.edu/~orso/pape rs/halfond.orso.woda05.pdf, Mai 2005 Rawat R., Kumar S., Samrat S. Ashok «SQL injection attack Detection using SVM», Technological Institute, March 2012 http://research.ijcaonline.org/volume 42/number13/pxc3877043.pdf - Chung Y-C., Wu M-C.,Chen Y-C, Chang W-K «A Hot Query Bank approach to improve detection performance against SQL injection attacks» http://tweb.cjcu.edu.tw/journal_abstr act/2012_11_07_09_51_15.737.pdf, Janvier 2012 [5] «Fonction dl_» http://php.net/manual/fr/function.dl.php Novembre 2013 [3] «xquery» http://fr.wikipedia.org/wiki/xquery Fevrier 2014 [4] «php-sql-parser» https://code.google.com/p/php-sql-parser Novembre 2013 9