Abonnez-vous à DeepL Pro pour traduire des fichiers plus volumineux.

Visitez www.DeepL.com/pro pour en savoir plus.

Université d'État de San Jose

SJSU ScholarWorks

Projets de master Thèses de master et recherches de

troisième cycle 2008

Analyse, détection et prévention des injections SQL

Jagdish Halde
Université d'État de San Jose

Suivez ce travail et d'autres à l'adresse suivante :

https://scholarworks.sjsu.edu/etd_projects Part of the Computer Sciences

Commons

Citation recommandée
Halde, Jagdish, "SQL Injection analysis, Detection and Prevention" (2008). Projets de maîtrise. 82.
DOI : https://doi.org/10.31979/etd.mnyq-9gq5
https://scholarworks.sjsu.edu/etd_projects/82

Ce projet de maîtrise vous est proposé en accès libre et gratuit par le service des mémoires de maîtrise et
de la recherche universitaire de SJSU ScholarWorks. Il a été accepté pour inclusion dans les projets de
maîtrise par un administrateur autorisé de SJSU ScholarWorks. Pour plus d'informations, veuillez contacter
scholarworks@sjsu.edu.
Analyse, détection et prévention des injections SQL

Un projet

d'écriture

présenté à

La faculté du département d'informatique San Jose

State University

En exécution partielle

des conditions d'obtention du

diplôme de Master of Science

Par

Jagdish Halde

Printemps

i
2008

ii
Copyright © 2008

Jagdish Halde

Tous droits réservés

iii
RÉSUMÉ

Les sites web sont dynamiques, statiques et, la plupart du temps, une combinaison

des deux. Les sites web ont besoin d'une protection de leur base de données pour assurer

leur sécurité. Une injection SQL attaque les applications web interactives qui fournissent

des services de base de données. Ces applications prennent en compte les entrées de

l'utilisateur et les utilisent pour créer une requête SQL au moment de l'exécution. Dans

une attaque par injection SQL, un pirate peut insérer une requête SQL malveillante

comme entrée pour effectuer une opération non autorisée sur la base de données. En

utilisant les attaques par injection SQL, un pirate peut récupérer ou modifier des

informations confidentielles et sensibles de la base de données. Cela peut compromettre

la confidentialité et la sécurité des sites web qui dépendent totalement des bases de

données. Ce rapport présente une "réingénierie du code" qui protège implicitement les

applications écrites en PHP contre les attaques par injection SQL. Il utilise une approche

originale qui combine l'analyse statique et l'analyse dynamique. [Dans ce rapport, j'ai

mentionné une technique automatisée pour éliminer les vulnérabilités d'injection SQL du

code Java en convertissant les entrées de texte brut reçues des utilisateurs en instructions

préparées. [3]

iv
REMERCIEMENTS

Je remercie mon conseiller, le Dr Robert Chun, dont les conseils, le soutien et le

dévouement sont inestimables. M. Chun est un éducateur au sens propre du terme. Je

remercie tout particulièrement l'IEEE (Institute of Electrical and Electronics Engineers,

Inc.) pour avoir fourni des informations récentes sur mon sujet.

Ce fut un parcours difficile, mais gratifiant, que je n'aurais pas pu mener à bien

seule et je vous suis reconnaissante de votre soutien.

Nous vous remercions.

1
Table des matières

1.0 Introduction 5

2.0 Travaux connexes 7

2.1 Techniques de découverte des injections SQL 9
2.2 Validation de l'arbre d'analyse SQL 9
2.3 Approche pour le contrôle SQL 11

3.0 Contexte de la déclaration SQL 13

3.1 Déclaration SQL 14
3.1.1 Déclaration préparée 14
3.1.2 Durée d'exécution du relevé automatisé 15

4.0 Rétablissement de la vulnérabilité 16

4.1 Constructeur de garde basé sur un modèle 17
4.2 Méthode de prévention de l'injection SQL 22
4.3 Analyse statique d'une procédure stockée 22
4.4 Avantages de l'analyse statique 24
4.5 Analyse dynamique 24

2
5.0 SQLiX - Scanner d'injection Sql : 26
5.1 SQLiX avant l'amélioration : 26
5.2 Modules Perl utilisés dans SQLiX 27

6.0 Améliorations apportées à SQLiX 30

6.1 Qu'est-ce que j'ai accompli ? 31
6.2 SQLiX HTTP Post Method et remplir le formulaire automatiquement 32
6.2.1 Travailler 32
6.2.2 Analyseur HTML 33
6.2.3 Formulaire HTML 33

7.0 Interface graphique SQLiX 34

8.0 Cross Site Scripting (XSS) 38

8.1 Type de XSS 39
8.2 Ce que j'ai fait dans SQLiX pour détecter les vulnérabilités XSS 39
8.3 Comment cela fonctionne-t-il ? 40
8.4 Petit bout de code ajouté pour l'ATTACK XSS et explication 40

9.0 Autre scanner d'injection sql commercial et source opérationnelle 42

9.1 Acunietix 42
9.2 Sqlmap 42
9.3 Wapiti 43
9.4 Paros 44
9.5 Pixy 45
9.6 Évaluation des performances de SQLiX avec des outils commerciaux et open source 45

10.0 Voir les graphiques 50

11.0 Site de test de vulnérabilité SQLiX Web : 52

12.0 Cas de test 54

13.0 Conclusion 57

14.0 Travaux futurs 59

Références 59

3
Liste des figures

Figure 1. Architecture d'une application Web .....................................................................6

Figure 2. Requête SELECT avec deux entrées utilisateur .................................................10
Figure 3. La même requête SELECT que dans la figure 1, avec l'entrée de l'utilisateur insérée
..........................................................................................................................................10
Figure 4. Une page JSP pour récupérer les numéros de cartes de crédit ...........................11
Figure 5. Architecture du système SQLCHECK...............................................................12
Figure 6. Protection automatisée .......................................................................................18
Figure 7. Exemple conceptuel de garde de modèle en Java ..............................................21
Figure 8. Graphique de contrôle SQL................................................................................24
Figure 9. Reconnaissance d'une attaque par injection SQL et contournement de SQL-FSM 25
Figure 10 : Avant le début de la numérisation..................................................................35
Figure 11 : Recherche de l'URL racine http://test.acunetix.com .......................................36
Figure 12 : Le résultat de l'analyse s'affiche dans la fenêtre de droite..............................37
Figure 13 : Le tableau montre l'évaluation des performances de SQLiX par rapport à d'autres
outils. ................................................................................................................................44
Figure 14 : Cas de test pour http://jagdishhalde.hostrator.com/indexacu.php....................46
Figure 15 : Cas de test pour http://test.acunetix.com.........................................................46
Figure 16 : Cas de test pour http://www.jeffgaroutte.com................................................47
Figure 17 : Cas de test pour http://abhishek1984.zxq.net..................................................47
Figure 18 : Cas de test pour http://inderweb.com .............................................................48
Figure 19 : Cas de test pour http://www.surfindia.com.....................................................48
Figure 20 : Visualiser les graphiques ................................................................................51
Figure 21 : Site de vulnérabilité de SQLiX Web avec page d'accueil du site source de SQLiX
..........................................................................................................................................52
Figure 22 : Site de vulnérabilité SQLiX Web avec page d'accueil et back-end ................53
Figure 23 : Site web de vulnérabilité SQLiX montrant des attaques de base par injection SQL
..........................................................................................................................................54
Figure 24 : Cas de test, analyse de http://test.acunetix.com à l'aide de SQLiX amélioré .57
Figure 25 : Cas de test, analyse de http:// test.acunetix.com montrant le résultat .............58
Figure 26 : Cas de test, analyse de http:// abhishek1984.xzq.net à l'aide de SQLiX amélioré 59

4
14.0. Introduction

Ces dernières années, l'adoption généralisée de l'internet a entraîné des progrès rapides

dans les technologies de l'information. L'internet est utilisé par l'ensemble de la

population à des fins telles que les transactions financières, les activités éducatives et

d'innombrables autres activités. L'utilisation de l'internet pour accomplir des tâches

importantes, comme le transfert du solde d'un compte bancaire, s'accompagne toujours

d'un risque de sécurité. Les sites web d'aujourd'hui s'efforcent de préserver la

confidentialité des données de leurs utilisateurs et, après des années de commerce en

ligne sécurisé, ces entreprises sont devenues des experts en matière de sécurité de

l'information. Les systèmes de base de données sur lesquels reposent ces sites web

sécurisés stockent des données non critiques ainsi que des informations sensibles, de

manière à permettre aux propriétaires des informations d'y accéder rapidement tout en

bloquant les tentatives d'intrusion de la part d'utilisateurs non autorisés.

Une stratégie d'intrusion courante consiste à essayer d'accéder à des informations

sensibles à partir d'une base de données en générant d'abord une requête qui provoquera

un dysfonctionnement de l'analyseur de la base de données, puis en appliquant cette

requête à la base de données souhaitée. Une telle approche pour accéder à des

informations privées est appelée injection SQL. Les bases de données étant

omniprésentes et accessibles depuis l'internet, il est plus important que jamais de se

préoccuper de l'injection SQL. Bien que les systèmes de base de données actuels soient

peu vulnérables, le Computer Security Institute a découvert que chaque année, environ 50

% des bases de données subissent au moins une faille de sécurité. La perte de revenus

5
associée à ces failles a été estimée à plus de quatre millions de dollars. En outre, des

recherches récentes menées par "Imperva Application

6
Defence Center" a conclu qu'au moins 92 % des applications web sont susceptibles de

faire l'objet d'une "attaque malveillante" (Ke Wei, M. Muthuprasanna, Suraj Kothari,

2007).

Pour mieux comprendre l'injection SQL, nous devons avoir une bonne compréhension

des types de communications qui ont lieu au cours d'une session typique entre un

utilisateur et une application web. La figure suivante montre l'échange de communication

typique entre tous les composants d'un système d'application web typique.

Figure 1 : "Architecture d'une application Web".

Source : Gary Wassermann Gary Wassermann Zhendong Su, Sound and
Precise Analysis of Web Applications for Injection Vulnerabilities, Université
de Californie, Davis, 2007.

Une application web, basée sur le modèle ci-dessus, prend du texte en entrée des

utilisateurs pour extraire des informations d'une base de données. Certaines applications

web supposent que l'entrée est légitime et l'utilisent pour construire des requêtes SQL afin

d'accéder à une base de données. Comme ces applications web ne valident pas les

requêtes des utilisateurs avant de les soumettre pour récupérer des données, elles

deviennent plus sensibles aux attaques par injection SQL. Par exemple, des attaquants, se

7
faisant passer pour des utilisateurs normaux, utilisent un texte d'entrée malveillant

contenant des instructions SQL pour produire des requêtes SQL sur l'application web

8
du côté de l'application web. Une fois traitée par l'application web, la requête

malveillante acceptée peut enfreindre les politiques de sécurité de l'architecture de la base

de données sous-jacente, car le résultat de la requête peut entraîner un dysfonctionnement

de l'analyseur de la base de données et la divulgation d'informations sensibles.

L'objectif de ce projet est d'élaborer une méthode automatisée de génération de

correctifs afin de prévenir les vulnérabilités par injection de code SQL à partir

d'instructions SQL en texte clair. Dans le cadre d'une méthode automatisée, un serveur

recueillera des informations sur les vulnérabilités précédemment connues, en particulier

les instructions SQL, générera un correctif et l'appliquera. Le processus peut être réalisé

par quelqu'un qui n'a pas d'expertise en matière de sécurité et qui sécurise le code

existant, ce qui permettra aux développeurs de corriger la vulnérabilité de l'injection

SQL.

2.0 Travaux connexes

J'ai examiné un certain nombre d'articles de revues électroniques de l'IEEE et de

l'ACM, et j'ai recueilli des informations sur des sites web afin d'acquérir des

connaissances suffisantes sur les attaques par injection de code SQL. Voici les articles

dans lesquels j'ai abordé différentes stratégies importantes pour prévenir les attaques par

injection de code SQL.

1. Dans "Using Parse Tree Validation to Prevent SQL Injection Attacks" ACM, j'ai

abordé les techniques de découverte des injections SQL. Cet article couvre également très

bien la validation de l'arbre d'analyse SQL que j'ai mentionnée dans le rapport (Gregory

T. Buehrer, Bruce W. Weide, et Paolo A. G. Sivilotti, 2005).

9
2. Dans "The Essence of Command Injection Attacks in Web Applications" ACM, ils ont

abordé les techniques de vérification et d'assainissement des requêtes d'entrée à l'aide de

SQLCHECK, qui utilise les requêtes augmentées et la grammaire SQLCHECK pour

valider les requêtes. (Zhendong Su et Gary Wassermann, 2006)

3. Dans le document "Using Automated Fix Generation to Secure SQL Statements" de

l'IEEE CNF, ils ont abordé brièvement le contexte, l'énoncé SQL et les méthodes de

remplacement des vulnérabilités (Stephen Thomas et Laurie Williams, 2007).

4. De "Protection automatisée des applications PHP contre les injections SQL

Attacks", ils ont présenté une méthode originale pour protéger automatiquement les

applications contre les attaques par injection de code SQL. L'approche originale combine

l'analyse statique, l'analyse dynamique et la réingénierie automatique du code pour

sécuriser les propriétés existantes (Ettore Merlo, Dominic Letarte, Giuliano Antoniol,

2007).

5. Dans "Preventing SQL Injection Attacks in Stored Procedures", ils ont également

proposé une nouvelle approche pour protéger les procédures stockées contre les attaques

et détecter les injections SQL à partir du site (Ke Wei, M. Muthuprasanna, Suraj Kothari,

2007). Cette méthode combine l'exécution

de l'analyse statique du code de l'application afin d'éliminer les vulnérabilités à l'égard des

attaque. La clé de cette attaque est qu'elle modifie la structure de l'instruction SQL

originale et identifie l'attaque par injection SQL. La méthode est divisée en deux phases,

l'une hors ligne et l'autre en cours d'exécution. Dans la phase hors ligne, les procédures

stockées utilisent un analyseur pour prétraiter et détecter les instructions SQL dans l'appel

d'exécution pour l'analyse d'exécution. Dans la phase d'exécution, la technique contrôle

toutes les requêtes SQL générées pendant l'exécution et liées à l'entrée de l'utilisateur, et

10
les vérifie par rapport à la structure originale de la requête SQL.

11
après avoir reçu les données de l'utilisateur. Une fois que cette technique détecte les

instructions SQL malveillantes, elle empêche l'accès de ces instructions à la base de

données et fournit des détails sur l'attaque.

2.1 Technique de découverte de l'injection SQL :

Il n'est pas nécessaire pour un attaquant de visiter les pages web à l'aide d'un

navigateur pour savoir si l'injection SQL est possible sur le site. En général, les attaquants

construisent un robot d'exploration du web pour collecter toutes les URL disponibles sur

chacune des pages web du site. Le crawler est également utilisé pour insérer des

caractères illégaux dans la chaîne de requête d'une URL et vérifier si le serveur envoie un

résultat d'erreur. Si le serveur envoie un message d'erreur, cela indique clairement que le

méta-caractère spécial illégal sera intégré à la requête SQL et que le site est donc exposé

à une attaque par injection SQL. Par exemple, Microsoft Internet Information Server

affiche par défaut un message d'erreur ODBC si un méta-caractère quelconque ou un

guillemet simple non encapsulé est transmis à SQL Server. Le robot d'exploration du web

ne recherche que les messages ODBC dans le texte de la réponse.

2.2 SQL PARSE TREE VALIDATION :

Un arbre d'analyse n'est rien d'autre que la structure de données construite par le

développeur pour la représentation analysée d'une déclaration. Pour analyser la

déclaration, la grammaire du langage de cette déclaration est nécessaire. Dans cette

méthode, en analysant deux déclarations et en comparant leurs arbres d'analyse, nous

pouvons vérifier si les deux requêtes sont égales. Lorsqu'un attaquant réussit à injecter du

code SQL dans une requête de base de données, l'arbre d'analyse de la requête SQL

12
prévue et l'arbre d'analyse de la requête de base de données sont comparés.

13
la requête SQL générée après l'entrée de l'attaquant ne correspond pas. La figure suivante

montre la représentation d'un arbre d'analyse. [4]

Figure 2 : Requête SELECT avec deux entrées utilisateur

Figure 3 : La même requête SELECT que dans la figure 1, avec l'entrée de l'utilisateur
insérée.

Dans l'arbre d'analyse ci-dessus, la partie fournie par le programmeur est codée en dur et

la partie fournie par l'utilisateur est représentée par un nœud feuille vacant dans l'arbre

d'analyse ci-dessus. Un nœud feuille doit être la valeur d'un littéral et doit se trouver à

l'endroit où se trouve l'espace vacant. La requête SQL pour l'arbre d'analyse ci-dessus est

la suivante.

SELECT * FROM users WHERE username= ? AND password= ?.

Les points d'interrogation sont des supports pour les nœuds feuilles d'entrée. [4]

14
2.3 Approche pour SQL CHECK :
<% !
// informations sur la connexion à la base de données
String dbDriver = "com.mysql.jdbc.Driver" ;
String strConn = "jdbc:mysql://"
+ "sport4sale.com/sport" ;
String dbUser = "manager"
;
Chaîne dbPassword = "athltpass" ;
// génère une requête à
envoyer String
sanitizedName =
replace(request.getParameter("name"),"'","''") ;
String sanitizedCardType =
replace(request.getParameter("cardtype"),
"'","''") ;
String query = "SELECT cardnum FROM accounts"
+ " WHERE uname='" + sanitizedName + "'"
+ " AND cardtype=" + sanitizedCardType + "
;"; try { // se connecter à la base de données
et envoyer la requête
java.sql.DriverManager.registerDriver(
(java.sql.Driver)
(Class.forName(dbDriver)).newInstance())) ;
javaq.sql.Connection conn =
java.sql.DriverManager.getConnecion(
strConn, dbUser, dbPassword) ;
java.sql.Statement stmt =
conn.createStatement() ;
java.sql.ResultSet rs =
stmt.executeQuery(query) ;
// génère une sortie html
out.println("<html><body><table>") ;
while(rs.next()) { out.println("<tr> <td>")
; out.println(rs.getString(1)) ;
out.println("</td> </tr>") ;
}if (rs != null) { rs.close() ;
}out.println("</table> </body> </html>") ;
} catch (Exception e)
{ out.println(e.toString()) ; } %>

Figure 4 : Une page JSP pour récupérer les numéros de cartes de crédit.

Les applications web présentent des vulnérabilités d'injection SQL parce qu'elles ne

nettoient pas les entrées qu'elles utilisent pour construire des sorties structurées. Prenons

l'exemple de l'extrait de code illustré à la figure 4. Le code est celui d'une boutique en

ligne. Le site web fournit un champ de saisie permettant à l'utilisateur de conserver les
15
informations relatives à sa carte de crédit, qu'il pourra utiliser lors d'achats ultérieurs.

Remplacer

16
est utilisée pour échapper aux guillemets, de sorte que tout caractère entre guillemets

simple dans l'entrée est considéré comme un caractère littéral et non comme un

délimiteur de chaîne. La méthode Replace est destinée à bloquer les attaques en

empêchant un pirate de terminer la chaîne et d'ajouter du code d'injection SQL. Bien que

cardtype soit une colonne numérique, si un pirate passe 2 OR 1=1" comme type de carte,

tous les numéros de compte de la base de données seront renvoyés et affichés. [5]

Figure 5. Architecture du système SQLCHECK.

Dans cette approche, ils suivent à travers le programme les sous-chaînes reçues de

l'entrée de l'utilisateur et nettoient ces sous-chaînes syntaxiquement. L'objectif de ce

programme est de bloquer les requêtes dans lesquelles les sous-chaînes d'entrée modifient

la structure syntaxique du reste de la requête. Il utilise les métadonnées pour surveiller les

entrées de l'utilisateur, affichées sous la forme de "_" et "_", pour marquer la fin et le

début de chaque chaîne d'entrée de l'utilisateur. Ces métadonnées font passer la chaîne

par des affectations et des concaténations, de sorte que lorsqu'une requête est prête à être

17
envoyée à la base de données, elle comporte des paires de marqueurs correspondants qui

identifient la sous-chaîne de l'entrée. Ces paires de

18
annotée, appelée requête augmentée. Pour construire un analyseur syntaxique pour la

grammaire augmentée et tenter d'analyser chaque requête augmentée, Steve [5] utilise un

générateur d'analyse. La requête répond aux contraintes syntaxiques et est considérée

comme légitime si elle est analysée avec succès. Dans le cas contraire, elle ne respecte

pas les contraintes syntaxiques et est interprétée comme une attaque par injection SQL.

L'architecture du système de vérification est présentée à la figure 5. La grammaire

du langage de sortie est utilisée pour construire SQLCHECK et une politique

mentionnant les formes syntaxiques autorisées, elle réside sur le serveur web et exploite

les requêtes générées. Malgré la source de l'entrée, chaque entrée qui doit être passée

dans une requête est augmentée des métacaractères "_" et "_,". Enfin, l'application crée

des requêtes augmentées que SQLCHEKCK tente d'analyser. Si une requête est analysée

avec succès, SQLCHECK envoie les métadonnées à la base de données, sinon la requête

est rejetée.

3.0 Contexte de la déclaration SQL

Cette section donne une brève idée de la vulnérabilité de l'injection SQL et des

attaques d'injection SQL qui y sont liées. La vulnérabilité par injection SQL est la

combinaison de la compilation dynamique d'instructions SQL et d'une faiblesse dans la

validation des entrées. Cette validation d'entrée force l'entrée à modifier la structure d'une

requête SQL. De telles combinaisons se retrouvent généralement en Java. L'exemple

suivant montre le code qui contient initialement une instruction SQL en texte brut et qui

produit dynamiquement la requête SQL sur la base d'une variable d'entrée (userISBN).

En outre, sans aucune vérification des entrées, il crée la requête SQL à l'aide de la

19
concaténation de chaînes de caractères.

"Statement stmt ="

"conn.createStatement() ;"

20
 "ResultSet rs = stmt.executeQuery("select
amount from" "books where isbn = '" +
userISBN + "'") ;"

Dans cet exemple, en utilisant des mots-clés connus de l'instruction SQL, l'attaquant

tente malicieusement de mettre à jour les informations sensibles dans les bases de

données. Ici, l'attaquant tente de modifier la structure de la requête exécutable, ce que le

système ne devrait pas permettre. L'attaquant peut donner les valeurs d'entrée

malveillantes de 111' OR '1'='1 pour l'utilisateur ISBN. La clause supplémentaire

"appended OR '1'='1 clause" rend toute la clause where toujours vraie et, par conséquent,

la requête ouvre la déclaration SQL pour récupérer et envoyer tous les résultats sans

articulation au lieu du résultat qui était censé être envoyé à l'utilisateur. L'attaque a réussi

grâce à la clause OR '1'='1 qui rend la valeur de la clause where vraie dans toutes les

conditions. [5]

3.1 Déclarations SQL

Deux types d'instructions SQL sont utilisés pour prévenir les attaques par injection SQL.

3.1.1 Déclarations préparées

Les instructions qui ont été pré-compilées avec la requête SQL sont appelées

instructions préparées. La requête SQL n'est rien d'autre que la représentation en texte

clair de la déclaration écrite par le programmeur lors du développement de l'accès

programmé à la base de données. Les instructions préparées dans les requêtes SQL lient

des variables qui vous permettent d'introduire des données dans les requêtes suivantes. En

Java, la méthode set input est utilisée pour définir une variable de liaison, par exemple

21
setString(index, output) pour une variable de sortie de type String. Les méthodes set

offrent la sécurité supplémentaire de confirmer chaque variable d'entrée par rapport à son

type déclaré. L'objectif premier de la méthode

22
L'objectif des instructions préparées est d'accroître la sécurité et l'efficacité. Les

instructions préparées sont conçues pour exécuter la même instruction un certain nombre

de fois lors de la compilation de l'instruction. Cette propriété n'est pas disponible dans les

instructions SQL en texte clair. La fonctionnalité de la fonction préparée est la même que

celle des instructions SQL en texte brut, mais les instructions préparées sont plus

structurées que les instructions SQL en texte brut. La manipulation de la structure de la

requête pré-compilée peut empêcher l'utilisation de la gestion de la structure de

l'instruction préparée, et donc exclure la vulnérabilité de l'injection SQL.

La limite des instructions préparées est qu'elles ne peuvent être créées que si la

structure de l'instruction est connue avant la création de l'instruction. Ainsi, les

instructions créées dynamiquement peuvent être créées en connaissant la structure de

l'instruction, ce qui n'est pas possible avec les instructions préparées. Les instructions

préparées sont précompilées, une fois que les instructions sont construites par l'objet

Connexion en Java. Lorsque toutes les entrées sont définies dans l'instruction et que celle-

ci est exécutée, elle est envoyée à la base de données. [7]

3.1.2 Temps d'exécution automatisé Déclaration

L'avantage de l'instruction automatisée est qu'elle vérifie la vulnérabilité des requêtes

SQL de manière dynamique au moment de l'exécution. Cette méthode ne dépend pas

seulement totalement de l'instruction préparée, elle valide également le code SQL en

imposant des contraintes à l'environnement d'exécution afin d'éviter les instructions SQL

malveillantes. Dans cette méthode, la solution proposée consiste à éviter une attaque par

injection SQL, en analysant l'arbre d'analyse de l'instruction SQL, en créant une

23
instruction SQL personnalisée.

24
de validation, et l'intégration de la déclaration susceptible dans le code de validation.

[Dans l'instruction automatisée au moment de l'exécution, Stephen Thomas utilise les

arbres d'analyse de manière dynamique pour effectuer la comparaison au moment de

l'exécution afin de déterminer si deux requêtes sont fonctionnellement identiques. L'arbre

d'analyse permet de découvrir la structure et les variables d'entrée de l'instruction SQL.

[9]

4.0 Vulnérabilité Réintégration

Pour obtenir un secret parfait, nous ajoutons l'instruction SQL sécurisée à l'instruction

vulnérable ou nous rétablissons l'intégralité de l'instruction vulnérable. Si l'objet

Connexion de la base de données est hors du champ d'application de l'appel d'exécution,

les instructions vulnérables se trouvent dans une signature de méthode. Si l'instruction

vulnérable se trouve dans l'état d'une méthode de signature détectable, il n'est pas

nécessaire de remplacer l'instruction. Dans certains cas, si nous modifions les

instructions, nous devons également modifier l'API. Nous pouvons obtenir le secret sans

changer ou modifier le code de création des instructions, mais pour éliminer la

redondance dans l'objet, nous devons remplacer complètement les instructions SQL en

texte clair. Dans les cas ci-dessus, nous remplacerons l'appel d'exécution par

PreparedStatement preparedStmt = Statement.getConnection().prepareStatement(ps

SQL) ;

il s'agit de l'appel à la formation de la déclaration préparée.

Déclaration : Objets Statement réels dans le code

Java. PSsql : requête SQL générée avec des

25
variables de liaison.

26
 L'appel de formation permet de prévenir les attaques par injection SQL en contournant

la déclaration et en créant une "déclaration préparée" sécurisée basée sur la déclaration

SQL. De cette manière, nous pouvons atteindre le secret parfait, prévenir la vulnérabilité

de l'injection SQL et l'attaque par injection SQL. [11]

4.1 Approche de prévention des constructeurs de garde basée sur un modèle

La prévention des constructeurs de garde basée sur un modèle est une méthode

efficace pour prévenir les attaques par injection de code SQL. Cette méthode est fondée

sur la rupture de la conjonction appropriée de l'entrée, du code, des données et de la

situation d'accès à la base de données qui emploierait une attaque par injection SQL. En

insérant spontanément des gardes appropriées avant d'autoriser l'accès à la base de

données, nous pouvons éviter une attaque par injection SQL. Comme le montre la figure

6, nous instrumentons d'abord la chaîne PHP pour collecter des échantillons de requêtes

utilisées de manière authentique au point d'appel de l'interface du programme

d'application de la base de données. Ces requêtes sont appelées un ensemble de cas de

test fiables. À partir du flux du diagramme, nous pouvons facilement comprendre la

prévention d'une attaque par injection SQL. L'instrumentation consiste simplement à

ajouter une instruction de sortie avant les appels à l'interface d'application de la base de

données, comme indiqué ci-dessous.

Sql_query(... Expression...) ;

Après avoir passé cette expression par une approche automatisée, elle devient :

$string = Expression ;
fRead($file handle ; $string)) ;
$result = sql_query($ string) ;
27
 Après avoir exécuté les cas de test fiables pour recueillir les chaînes de texte en clair

produites dynamiquement sur différents sites d'appel correspondant à des requêtes

fiables, il est facile de créer des protections de modèle à partir d'ensembles d'AST

conduisant à des requêtes légitimes. Il est facile de créer des gardes-modèles à partir

d'ensembles d'AST conduisant à des requêtes légitimes. Les requêtes justifiables sont

analysées par une approche automatisée et les "AST" correspondants sont stockés pour

chaque site d'appel. Pour éviter la généralisation entre les requêtes, les "AST" sont

stockés indépendamment. [13]

28
Figure 6 : "Protection automatisée" [13]

29
 Les AST sont généralisés par type plutôt que par image, car les constantes, les chaînes

et d'autres types de données sont également stockés dans les AST. D'autre part, les

identificateurs dépendant de l'application, tels que les noms des tables, le nombre de

colonnes et de lignes, sont considérés comme faisant partie de la structure syntaxique de

la requête SQL, ce qui joue un rôle crucial pour empêcher la substitution malveillante des

noms de tables ou de colonnes dans les requêtes valides. Par conséquent, cette méthode

permet un certain nombre de requêtes avec la même structure syntaxique, mais avec des

valeurs de données différentes. À l'aide d'un site d'appel spécial, le gardien de modèle

invoque l'analyseur SQL de la base de données sur laquelle nous travaillons actuellement

et obtient l'AST SQL correspondant. L'"AST" formé est comparé aux "AST" valides

stockés pour le même site d'appel. Si la correspondance aboutit à un résultat positif, la

requête actuelle a une structure syntaxique compatible avec la requête valide de

l'ensemble de confiance. Seules les requêtes positivement équivalentes sont autorisées à

être traitées dans l'interface de programmation de la base de données, et toutes les autres

requêtes sont rejetées. De cette manière, nous empêchons l'accès à la base de données à

partir de requêtes malveillantes élaborées.

En général, les "AST" sont stockés sous forme d'images, mais ils sont stockés sous

forme de chaînes de jetons contenant des types de jetons où les noms de tables et de

champs d'une application sont devenus des mots-clés. Les noms des tables ont été stockés

en tant que types de jetons d'identification dans la configuration locale. Dans la section

suivante, ces chaînes de jetons sont appelées motifs de référence.

Un exemple de requête fiable est présenté ci-dessous. Dans cet exemple, l'appel au

snooping à la ligne 333 du fichier browse.php est le suivant.

"SELECT post id"

30
"FROM phptb240t posts"
"OÙ"
"Poster_id = 5"

31
Où phptb240 posts est un nom de table locale dépendant de la configuration. L'identifiant

de l'affiche est un nom de champ défini dans la logique de l'application.

Les modèles de référence liés à la requête ci-dessus sont les suivants :

browse:php : 240
"SELECT POST ID"
"FROM SQL ID"
"WHERE"
"POSTER ID OP EQUAL INTEGER LITERAL"

Dans l'exemple ci-dessus, nous pouvons observer que les posts phptb240 sont

discernés comme un identifiant, et que l'identifiant du poster est utilisé comme mot-clé

d'une application. En raison de la même structure syntaxique d'une requête valide et du

remplacement des noms de champs par des noms confidentiels, nous devons prévenir les

attaques par injection SQL. L'identifiant de l'affiche et l'identifiant du poster dans

l'exemple ci-dessus peuvent être accédés dans n'importe quelle configuration locale de

phptb, mais ils ne seront pas remplacés par d'autres champs. Comme dans l'exemple

précédent, la valeur de l'identifiant de l'affiche ne peut être remplacée que par une valeur

entière. Les instructions de requête SQL sensibles peuvent être sécurisées en les

remplaçant par des protections basées sur un modèle qui exécutent les contrôles

appropriés à chaque site d'appel et autorisent l'accès à l'interface de programmation

d'application de la base de données appropriée pendant que les contrôles sont réussis.

Nous avons eu besoin de protections basées sur un modèle et de la réingénierie du code

source pour changer l'appel de mySql aux protections basées sur un modèle". La figure 7

montre un exemple de garde basé sur un modèle écrit en Java.

32
 Figure 7 : Exemple conceptuel de garde de modèle en Java. [13]

En appelant correctement la garde basée sur le modèle, nous pouvons protéger

l'application contre une attaque par injection de code SQL. La construction de la garde

basée sur un modèle est équivalente à la longueur moyenne des requêtes SQL exécutées

dans le test et au nombre de cas de test. Ettore Merlo, Dominic Letarte et Giuliano

Antoniol ont utilisé un processus de construction automatisé pour les garde-modèles.

33
qui est très simple et qui a une portée suffisante pour rendre ce modèle plus compliqué

afin d'augmenter la puissance des requêtes d'analyse. Le modèle de garde est bien

meilleur que la forme fixe par méthode de site d'appel. La construction du modèle de

garde dépend automatiquement de l'approximation dynamique pour la spécification de la

sécurité. Le faible nombre de requêtes légitimes sur un site d'appel affecte également

l'efficacité de l'automatisation. Cette approche fournit un niveau de protection réalisable

contre une attaque par injection SQL. [13]

4.2 Prévention de l'injection SQL method

Stephen Thomas et Laurie Williams ont expliqué en détail les méthodes utilisées pour

prévenir les attaques par injection SQL. [2]

1) Analyse statique

2) Analyse de la durée d'exécution

Ces techniques sont basées sur les procédures stockées, les auteurs ont utilisé le

graphique de flux de contrôle qui notifie les entrées de l'utilisateur dans l'instruction SQL

dynamique construite. Les graphes de flux de contrôle sont très utiles pour minimiser

l'ensemble des instructions SQL à vérifier. Dans l'analyse du temps d'exécution, nous

accédons aux informations sur les instructions stockées de l'Automate à états finis pour

réduire la procédure de vérification et indiquer si les entrées de l'utilisateur sont vraies ou

fausses. [2]

4.3 Analyse statique d'une procédure stockée

Dans l'analyse statique, les auteurs fournissent un analyseur appelé analyseur de

34
procédures stockées qui est utilisé pour extraire le "graphe de flux de contrôle" des

procédures stockées, nous pouvons voir en détail le graphe de contrôle dans la section

suivante. Au départ, nous étiquetons chaque exécution

35
dans le graphe de flux de contrôle, puis utiliser la méthode de retour en arrière pour

vérifier que toutes les instructions ont participé à la formation de l'instruction SQL dans

le graphe de flux de contrôle. Dans le graphe SQL, les instructions qui dépendent de

l'entrée de l'utilisateur sont filtrées et des drapeaux sont placés dessus pour surveiller leur

comportement au moment de l'exécution. Dans cette méthode, à l'aide de l'automate à

états finis, nous comparons l'instruction avec l'instruction SQL créée dynamiquement à

partir des entrées de l'utilisateur avec l'instruction SQL d'origine. L'instruction créée par

l'entrée de l'utilisateur qui tente de modifier le modèle original de l'analyseur syntaxique

sera signalée par un drapeau comme instruction dangereuse et fournira les informations

correspondantes. Plusieurs instructions d'exécution peuvent être possibles pour une seule

instruction de "procédure stockée". Il existe différents types d'instructions de procédure,

et seules les instructions qui acceptent l'entrée de l'utilisateur sont vulnérables à une

attaque par injection SQL. En utilisant le graphe de contrôle SQL, nous essayons

d'optimiser la requête qui doit être traitée dynamiquement afin de fournir une validation.

La figure suivante permet de comprendre clairement l'analyse statique. Quatre requêtes

SQL différentes Q1, Q2, Q3 et Q4 se trouvent dans la procédure stockée et sont

représentées par des nœuds à l'intérieur d'une limite représentée par un cercle en

pointillés. I1, I2 et I3 sont les trois entrées différentes reçues des utilisateurs, qui se

trouvent à l'extérieur des limites logiques. Supposons qu'un utilisateur saisisse l'entrée I

dans la requête SQL Q et que la relation entre l'entrée I et la requête Q soit représentée

par R. D représente les dépendances dans le diagramme SQL qui lie une requête SQL à

une autre. L'entrée de l'utilisateur "I" acceptée par la requête précédente est transférée à

une autre requête par le biais du lien de dépendance. Dans les requêtes SQL, l'un de ces

nœuds est sélectionné comme requête représentative et est considéré comme le point de
36
départ des autres requêtes. Dans la figure, les liens de dépendance sont représentés par

des flèches dirigées.

[1] [2]

37
 Figure 8 : Graphique de contrôle SQL [1]

4.4 Avantages de l'analyse statique

1) La représentation graphique SQL est utilisée pour réduire la charge d'exécution du

programme en évitant le nombre de requêtes qui ne doivent pas être exécutées

dans la procédure stockée.

2) Le graphe de contrôle SQL n'inclut pas la requête qui ne prend pas en compte les

données de l'utilisateur.

3) Les requêtes qui comprennent l'entrée de l'utilisateur pour accéder aux

informations de la base de données sont prises en compte dans la représentation

du graphe de contrôle SQL.

4.5 Analyse dynamique

Dans l'analyse dynamique, la fonction de vérification des attaques par injection SQL

est utilisée pour catégoriser les entrées de l'utilisateur. Dans cette méthode, l'auteur a

utilisé l'identifiant de la "session en cours" pour identifier les données saisies par

l'utilisateur, et en utilisant le même identifiant de session, il construit un automate à états

38
finis. Figure 5

39
montre l'automate à états finis qui accepte les entrées de l'utilisateur. Pour vérifier la

légitimité de la déclaration SQL reçue de l'utilisateur, la déclaration SQL avec les entrées

de l'utilisateur est comparée à la déclaration SQL correspondante de l'automate à états

finis. Si les requêtes SQL générées au moment de l'exécution à l'aide des entrées de

l'utilisateur ne satisfont pas à la sémantique des requêtes SQL prévues dans l'automate à

états finis, ces requêtes SQL sont considérées comme une attaque par injection de code

SQL ; dans le cas contraire, ces requêtes sont autorisées à accéder à la base de données.

Figure 9 : Reconnaissance d'une attaque par injection SQL et contournement de SQL-

FSM

Ainsi, nous pouvons facilement éviter les requêtes malveillantes élaborées et

n'autoriser que les requêtes légitimes à accéder aux bases de données. Grâce à l'utilisation

d'automates à états finis, cette méthode permet d'obtenir un secret parfait pour filtrer les

requêtes légitimes. [12]

40
5.0 SQLiX - Sql Injection Scanner :

5.1 SQLiX avant l'amélioration de :

SQLiX Scanner est disponible sur le site de l'Open Web Application Security Project

(OWASP). L'OWASP est une communauté mondiale libre et ouverte qui se consacre à

l'amélioration de la sécurité des logiciels d'application. SQLiX est codé en Perl, capable

d'explorer, de détecter une injection SQL et d'identifier la vulnérabilité de la base de

données dorsale. SQLiX utilise divers modules Perl de CPAN - CPAN n'est rien d'autre

que le Comprehensive Perl Archive Network (réseau complet d'archives Perl). Sur

CPAN, vous pouvez trouver un grand nombre de logiciels Perl et leur documentation afin

que n'importe quel codeur puisse utiliser ces bibliothèques et modules Perl dans ses

projets. Nous verrons plus en détail les modules Perl utilisés par SQLiX dans la section

des modules Perl.

Voici les méthodes utilisées dans la version originale de SQLiX :

1) Génération d'erreurs : La méthode de génération d'erreurs est très simple et dépend

généralement de méta-caractères tels que les guillemets simples et les guillemets doubles.

2) Méthode d'injection aveugle : Dans les méthodes d'injection SQL aveugle, les

applications web qui sont vulnérables à l'injection SQL ne sont pas visibles pour un

attaquant. Ces attaques sont affichées différemment en fonction des résultats d'une

instruction logique injectée dans la base de données.

3) Injection d'une déclaration : L'exemple suivant permet de comprendre clairement la

méthode d'injection de déclarations.

L'URL original :

0) est http:// localhost/acu/indexacu.php/news.php?id=25.

SQLiX essaie de comparer le contenu html de la requête originale avec les URL suivantes.
41
i) http://localhost/acu/indexacu.php/news.php?id=25%20or%201=1

42
ii) http://localhost/acu/indexacu.php/news.php?id=25%20or%201=0

si l'URL i) fournit le même résultat qu'une requête http 0) et que l'URL ii) ne le fait pas,

le SQLiX conclura qu'une injection SQL est possible sur l'URL donnée.

SQLiX utilise également plusieurs méthodes pour déterminer si le script côté serveur actuel est

vulnérable à l'injection SQL.

1) Injection d'erreurs conditionnelles.

2) Injection aveugle basée sur des nombres entiers, des chaînes de caractères ou des
instructions.

3) Messages d'erreur MS-SQL.

4) Il est également capable de reconnaître la version de la base de données.

SQLiX possède trois API principales qui permettent de construire les différents types

d'attaques SQL. SQLiX.pl est le fichier principal qui gère et invoque ces API sur chaque

URL empilée.

L'exemple suivant permet de comprendre clairement l'utilisation de la ligne de commande

en Perl SQLiX.pl -crawl="http://test.acunetix.com" -

exploit - method_taggy -v=5

5.2 Modules Perl utilisés dans SQLiX :

Crawl est la spécification cible qui prend l'URL donnée comme URL principale et

parcourt toutes les pages web et tous les formulaires disponibles sous cette URL. La

spécification cible crawl utilise le module Perl pour crawler.

Le crawler a besoin du module Perl Spider.pm pour parcourir l'ensemble du site web et

collecter toutes les URL disponibles sur chaque page et les empiler dans un tableau pour

la suite des opérations. Pour récupérer

43
Pour collecter les URL des pages et des formulaires, SQLiX utilise le module Perl

Mechaniz.pm. C'est le cœur de l'outil qui joue un rôle crucial dans la collecte des URL

pour la suite du processus. SQLiX utilise le module Checksite.pm pour vérifier et valider

l'URL disponible sur chaque page web du site. Il valide d'abord l'URL, puis l'empile pour

la suite de l'opération d'injection SQL. Le Spider utilise le mécanisme des règles du robot.

Cela signifie qu'il récupère toujours le fichier /robots.txt à la racine du serveur web pour

voir si nous sommes autorisés (en fait "non interdits") à accéder aux pages en tant que

robot. Spider utilise RobotRule.pm pour lire le fichier robot.txt disponible sur le serveur

et, conformément aux règles, il accède aux URL du site. Si le propriétaire du site interdit

l'exploration de certaines URL de son site, il doit inscrire ces URL dans le fichier

robot.txt afin que personne ne puisse explorer ces URL. Cette règle est suivie par tous les

développeurs de crawlers.

SQLiX possède une fonction très intéressante et importante par rapport aux autres

scanners : la possibilité de créer sa propre fonction. Vous pouvez créer votre propre

fonction pour injecter un code malveillant dans la base de données et tester différentes

vulnérabilités. Cette fonction n'est pas disponible dans les autres scanners de vulnérabilité

disponibles sur le marché. De plus, au lieu d'indiquer l'URL principale dans l'interface de

ligne de commande pour l'exploration, vous pouvez énumérer le nombre d'URL

principales que vous souhaitez explorer dans un fichier et appeler ensuite ce fichier.

L'option Exploit est utilisée pour attaquer l'une des vulnérabilités qui ont été trouvées

dans l'attaque par injection et tentera d'extraire des informations. Par défaut, la version de

la base de données est affichée.

44
V est l'option utilisée pour afficher le message de débogage et les informations sur les

vulnérabilités. Elle a une valeur de verbosité différente pour l'affichage d'informations

minimales et d'informations de débogage maximales sur toutes les URL, de 0 à 5.

Voici la sortie de SQLiX à l'aide de l'interface de ligne de commande :

C:\SQLix\SQLiX_v1.0>
C:\SQLix\SQLiX_v1.0>perl SQLiX.pl -crawl="http://test.acunetix.com" -all -exploit -v=2
======================================================
-- SQLiX --
⌐ Copyright 2006 Cedric COCHIN, tous droits réservés.
======================================================

Analyse des URI obtenus par crawling

[http://test.acunetix.com] http://test.acunetix.com/
http://test.acunetix.com/privacy.php
http://test.acunetix.com/userinfo.php
http://test.acunetix.com/login.php
http://test.acunetix.com/signup.php
http://test.acunetix.com/AJAX/index.php
http://test.acunetix.com/guestbook.php
http://test.acunetix.com/cart.php
http://test.acunetix.com/disclaimer.php
http://test.acunetix.com/artists.php
http://test.acunetix.com/comment.php?aid=3
[+] travailler sur l'aide
[+] Méthode : Message d'erreur MS-
SQL [+] Méthode : Message d'erreur
SQL
[+] Méthode : Injection de commentaires
MySQL [ERREUR] Le paramètre n'a pas
d'impact sur le contenu
[+] Méthode : Injection de chaîne SQL aveugle
[ERROR] Le paramètre n'a pas d'impact sur le contenu
http://test.acunetix.com/artists.php?artist=3
[+] travailler sur l'artiste
[Méthode : Message d'erreur MS-
SQL [+] Méthode : Message d'erreur
SQL
[+] Méthode : Injection de commentaires MySQL
[TROUVE] Injection de commentaires MySQL (basée sur des
entiers) [TROUVE] Injection de commentaires MySQL
http://test.acunetix.com/listproducts.php?artist=3
[+] travailler sur l'artiste
[Méthode : Message d'erreur MS-
SQL [+] Méthode : Message d'erreur
SQL
[WARNING] Match found in reference(NULL) - Vous avez une
erreur dans votre syntaxe SQL
45
[INFO] Erreur avec les citations
[INFO] Fonction courante : version()

46
 [INFO] longueur : 255

[FOUND] Message d'erreur SQL

http://test.acunetix.com/comment.php?aid=2
[+] travailler sur l'aide
[Méthode : SQL Blind Integer Injection [ERROR]
Le paramètre n'a pas d'impact sur le
contenu.
[+] Méthode : SQL Blind Statement Injection
[ERROR] Le paramètre n'a pas d'impact sur le
contenu.
[+] Méthode : Injection de chaîne SQL aveugle
[ERREUR] Le paramètre n'a pas d'impact sur le contenu

RÉSULTATS :
La variable [artiste] de [http://test.acunetix.com/artists.php?artist=3] est
susceptible de faire l'objet d'une injection SQL [Commentaire sans guillemets -
MySQL].
La variable [artist] de [http://test.acunetix.com/listproducts.php?artist=3] est
vulnérable à l'injection SQL [Message d'erreur (NULL) - MySQL].
La variable [pic] de [http://test.acunetix.com/product.php?pic=7] est vulnérable à
l'injection SQL [Commentaire sans guillemets - MySQL].
La variable [cat] de [http://test.acunetix.com/listproducts.php?cat=4] est
vulnérable à l'injection SQL [Message d'erreur (NULL) - MySQL].

A partir du résultat, vous pouvez vous faire une idée de la manière dont SQLiX collecte

toutes les URL du site web et détecte les URL vulnérables qui sont susceptibles de faire

l'objet d'une attaque par injection de code SQL.

6.0 Améliorations apportées à SQLiX :

6.1 Ce que j'ai réalisé sur ?

J'ai réalisé avec succès trois améliorations majeures dans le cadre de ce projet

i) Amélioration du crawler pour qu'il gère la méthode HTTP post et remplisse les formulaires
automatiquement.

ii) Création de l'interface utilisateur graphique (GUI) pour SQLiX.

iii) Ajout d'un module de détection des attaques de type Cross Site Scripting (XSS).

47
6.2 SQLiX HTTP Post Method et remplir automatiquement le formulaire :

Améliorer le crawler pour qu'il puisse gérer la méthode HTTP Post et remplir les

formulaires disponibles sur la page web est l'une des étapes les plus difficiles et les plus

critiques de mon projet. Cette amélioration a rendu SQLiX plus puissant que le précédent.

6.2.1 Travailler :

Après amélioration, le crawler est capable de traiter les requêtes de la méthode HTTP

Post. Le crawler est également capable de détecter et de remplir les formulaires

disponibles sur la page web en cours. Après avoir détecté les formulaires sur la page Web

actuelle, mon code vérifie le type d'entrée, le nom du type d'entrée et le type de type

d'entrée de chaque champ du formulaire. Dans l'étape suivante, mon code remplit les

données fictives dans chaque champ du formulaire en fonction de leur type. Une fois les

données fictives remplies, la fonction $response = $ua->request($form->click) soumet les

données dans la base de données et génère le contenu. Le contenu n'est rien d'autre que le

lien créé à partir de tous les noms de champs du formulaire et des données fictives

correspondantes. Enfin, dans la dernière étape, mon code transmet ce contenu au

programme principal SQLiX .pl pour créer différentes combinaisons de l'URL d'origine

pour ce formulaire particulier. L'étape d'injection commence alors et le contrôle est

transféré à la méthode qui injecte toutes les combinaisons d'URL dans la base de données

afin d'obtenir des informations non autorisées. La capacité de SQLiX à injecter un certain

nombre d'informations dans la base de données augmente considérablement, car il

applique la méthode d'injection à chaque champ du formulaire au lieu de l'appliquer

uniquement à l'URL principale.

Pour mettre en œuvre ce module, j'ai utilisé les modules Perl CPAN suivants.

i) Agent utilisateur LWP

48
ii) Html::parse

49
iii) Html::Form

LWP user agent est le module Perl utilisé pour implémenter l'agent utilisateur. En fait,

UserAgent est une classe dont j'utilise les objets pour envoyer des requêtes web. En

général, une application crée un objet LWP::UserAgent, configure cet objet avec des

paramètres, puis crée une instance de HTTP::Request pour la requête à effectuer. Cette

requête est ensuite transmise à l'une des méthodes de requête de UserAgent. UserAgent

vous répond alors sous la forme d'un objet HTTP::Response. Il existe trois méthodes

pratiques pour envoyer et recevoir des requêtes courantes : GET ( ), POST ( ) et HEAD (

). Ces méthodes cachent la création de l'objet de requête. Pour que chaque

communication soit ressentie comme un style http, cette bibliothèque construit des objets

HTTP::Request et HTTP::Response même pour les ressources non http.

Les méthodes de construction suivantes sont disponibles pour créer un objet :

$ua = LWP::UserAgent->new (%options)

Cette méthode construit un nouvel objet LWP::UserAgent et le renvoie. Vous devez fournir

des arguments sous forme de paires clé/valeur pour définir l'état initial. Maintenant, $ua

est le gestionnaire de l'objet LWP::UserAgent.

6.2.2 HTML Parser :

Le module HTML Parser est utilisé pour créer un objet qui reconnaîtra et différenciera

le balisage et le texte brut dans les documents HTML. Les objets de cette classe

reconnaissent les différents types de balises et de texte et invoquent les gestionnaires

d'événements correspondants. Le document que vous devez transmettre peut être transmis

par morceaux arbitraires. Je transmettrai les URL qui sont empilées par le robot

d'exploration. L'analyseur analyse l'URL donnée et sépare les éléments suivants

50
et le texte du html. Après avoir empilé toutes les balises dans un tableau local, ce tableau

sera utilisé pour le module Perl suivant, à savoir le formulaire HTML.

6.2.3 HTML Formulaire :

L'objet de la classe HTML Form a une seule instance, à savoir HTML<form>...</form>.

En général, un formulaire se compose d'un certain nombre de types d'entrées qui ont

généralement des noms et qui peuvent avoir divers attributs et valeurs. L'état d'un

formulaire peut être extrait et appelé à fournir un objet HTTP::Request qui peut être

transmis à la méthode appelée request( ) de LWP::UserAgent. Les méthodes disponibles

sont les suivantes :

@forms = HTML::Form->parse( $response )

@forms = HTML::Form->parse( $html_document, $base )

@forms = HTML::Form->parse( $html_document, %opt )

Un document HTML sera analysé et créera des objets HTML::Form pour chaque élément de
formulaire.

dans ce document à l'aide de la méthode de classe paser(). Si vous appelez cette méthode

dans un contexte scalaire, elle ne renvoie que le premier formulaire, et si elle renvoie une

liste vide, c'est qu'aucun formulaire n'a été trouvé. La variable $base est utilisée comme

URI pour récupérer le document $html_document. Si vous récupérez ce document à

l'aide de LWP, ce paramètre de HTML::Form obtenu à partir de la variable $response-

>bas() comme indiqué ci-dessus.

Voici le petit extrait que j'ai utilisé pour récupérer le contenu des formulaires.

use LWP::UserAgent
; use HTML::Form ;

my $ua = LWP::UserAgent->new ;
my $response = $ua->get("http://www.tizag.com/htmlT/forms.php") ;
#my $response = $ua->get("http://localhost/form.php") ;

51
my @forms = HTML::Form->parse($response) ;
foreach (@forms)
{

52
 my $form = $_ ;
print stdout "Form :" ;
print stdout "\n" ;
my @inputs = $form->inputs ;
foreach (@inputs)
{
my $input = $_ ;
print STDOUT $input->type ;
print " : " , $input->name ;
print stdout "\n" ;
}
print stdout "\n"
; print stdout
"\n" ;
}

7.0 SQLiX GUI :

SQLiX n'avait pas d'interface graphique ; l'utilisateur devait se souvenir de toutes les

options. Comme il possède une longue liste d'options, il est très encombrant si vous devez

attaquer un site avec un maximum d'options.

Pour l'option de fichier permettant de spécifier l'URL cible, l'utilisateur peut directement

sélectionner le fichier à partir de la boîte de dialogue Choix de fichier. Grâce à l'interface

graphique, l'utilisateur peut sélectionner les options directement. Le résultat de l'attaque

peut être enregistré dans un fichier spécifié. Vous trouverez ci-dessous des instantanés de

l'application.

53
Figure 10 : Interface graphique avant le début du balayage

54
 Figure 11 : Lors de la recherche de l'url racine http://test.acunetix.com.

La capture d'écran ci-dessus montre clairement que le nouvel utilisateur n'a besoin de se

souvenir d'aucune option. Il peut effectuer différents types de tests en sélectionnant

diverses options dans l'interface graphique. La barre de progression indique l'état de

l'analyse, ce qui n'est pas possible en ligne de commande.

55
Figure 12 : Le résultat de l'analyse s'affiche dans la fenêtre de droite.

56
8.0 Cross Site Scripting (XSS) :

Le Cross Site Scripting est l'une des attaques les plus courantes de la couche

d'application. XSS cible les scripts, qui font partie de la page web et sont exécutés du côté

de Clint au lieu du côté du serveur. Les attaques par scripts intersites peuvent se produire

chaque fois qu'un utilisateur a la possibilité de publier du contenu sur un site web de

confiance. Un utilisateur malveillant peut créer un script côté client, qui exécute une

activité telle que l'envoi de toutes les informations sensibles disponibles dans le

navigateur actuel à une adresse électronique particulière. Si ce script semble légitime et

que l'entrée n'est pas vérifiée, il sera chargé et exécuté par chaque utilisateur visitant le

site web. L'attaquant peut effectuer différents types d'attaques à l'aide de XSS. Par

exemple, il peut exécuter un contrôle "Active X" à partir de sites considérés comme

dignes de confiance. L'attaquant peut également soumettre le script XSS qui attire

l'attention de l'utilisateur. Les attaquants utilisent les scripts suivants.

<form> action="logoninformation.jsp" method="post"

onsubmit="hackImg=new Image ;
hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.value'+':'+
document.forms(1).password.value ;"
</form>

Ce script est utilisé pour voler les informations de connexion de l'utilisateur.

L'attaquant insère le script sur le site web et lorsqu'un utilisateur attiré clique sur le lien,

le script est exécuté et envoie les informations de connexion du site ciblé dans le script.

L'attaquant doit maintenant se rendre sur le site ciblé pour récupérer les informations de
connexion. [17]

57
8.1 Type de XSS :

Il existe deux grands types de XSS.

i) XSS non permanent : pour les attaques XSS non permanentes, l'utilisateur doit

visiter un lien qui attire son attention et qui est conçu avec un code malveillant. Lors

de la visite de ces liens, le code inséré dans l'URL sera imprimé et exécuté sur le

navigateur web de la victime.

ii) XSS permanent : ce type de XSS, également appelé vulnérabilité stockée, est plus

dangereux que le XSS non permanent. Dans le cas d'un XSS permanent, les

données fournies par l'utilisateur sont stockées en permanence sur le serveur, et

l'utilisateur malveillant stocke le code de script malveillant sur le serveur.

Généralement, il stocke ce type de données dans un formulaire de commentaires ou

de suggestions. Lorsque l'utilisateur normal recherche l'avis d'autres utilisateurs sur

un sujet particulier et que le script malveillant est récupéré sur le serveur, il est

exécuté sur le navigateur web de la victime. Selon l'intensité du script, il affecte

l'ordinateur de la victime. [19]

8.2 Ce que j'ai fait dans SQLiX pour détecter les vulnérabilités XSS :

Pour détecter le XSS à partir du site web donné, j'ai ajouté les deux fonctions suivantes

à SQLiX :

i) SET XSS

ii) ATTENTAT XSS

58
La fonction SET XSS est utilisée pour prendre la pile d'URLs dans la mémoire tampon et

la transmettre à la fonction Attack XSS. Il s'agit d'une fonction importante qui utilise la

charge utile et tente différentes attaques sur la liste d'URL. Si l'un des cas de test de la

charge utile réussit, l'URL en question est vulnérable à l'attaque XSS.

8.3 Comment cela fonctionne-t-il ?

Le script utilise la bibliothèque Web spider pour vérifier les règles mentionnées ci-dessous.

Le script analyse les pages web et recherche des scripts et des formulaires dans lesquels il

peut injecter des données.

Le site est vulnérable dans les conditions suivantes

i) Vérifie si un script autorise le téléchargement http.

ii) Lorsque le code de retour est http 500

8.4 Petit extrait de code ajouté pour l'ATTACK XSS et explication :

Attaque XSS :
def attackXSS(self,page,dict) :
si dict=={} :
err=""
payload="<script>var SQLiX_"
payload+=page.encode("hex_codec")
payload+="_"

payload+="QUERYSTRING".encode("hex_codec")
payload+="=new Boolean();</script>" url=page+"
? "+payload
if url not in self.attackedGET :
essayer :
si self.verbose==2 :
print "+"+url
req = urllib2.Request(url)
u = urllib2.urlopen(req)
data=u.read()
except (urllib2.URLError,socket.timeout),e
: if hasattr(e, 'code') :

59
 data=""
else :
retour
si data.find(payload)>=0 :
{
print "XSS (QUERY_STRING) dans",page
print "\tEvil url :",url
}
d'autre part :
si u.code==500 :
print "500 HTTP Error code with"
print "\tEvil url :",url
self.attackedGET.append(url)
for k in dict.keys() :
err=""
tmp=dict.copy()
payload="<script>var SQLiX_"
payload+=page.encode("hex_codec")
payload+="_"
payload+=k.encode("hex_codec")
payload+="=new Boolean();</script>"
tmp[k]=payload

if data.find(payload)>=0
: if self.color==0 :
print "XSS ("+k+") in",page
print "\tEvil url :",url
d'autre part :
print "XSS",":",url.replace(k+"=","\033[0;31m"+k+"\033[0;0m=")
else:
si u.code==500 :
print "500 HTTP Error code with"
print "\tEvil url :",url
self.attackedGET.append(url)

Dans l'extrait ci-dessus, la fonction AttackXss utilise l'ensemble de la charge utile pour

vérifier les scripts disponibles dans la base de données donnée et les associer à l'URL

donnée. La charge utile applique différentes opérations de test spécifiées dans la charge

utile. Nous ne vérifions que les XSS normaux et les XSS permanents. Il existe également

différents types de XSS qui peuvent être détectés en améliorant la charge utile.

60
9.0 Autres scanners d'injection SQL commerciaux et open source :

9.1 Acunetix web vulnerability scanner (analyseur de vulnérabilité web) :

Le scanner Acunetix divise le type d'analyse en fonction de la gravité du type

d'attaque web. Il se divise en quatre types : gravité élevée, moyenne, faible et

informationnelle. Acunetix est utilisé pour détecter différents types de vulnérabilités web,

comme indiqué ci-dessous.

i) Injection SQL

ii) Scripts croisés (cross site scripting)

iii) Scripts CGI

iv) Pare-feu et SSL

v) Redirection d'URL

L'injection SQL et les scans de scripts intersites relèvent du type de gravité élevée, car ils

sont considérés comme les attaques les plus dangereuses en matière de sécurité sur le

web. Les autres attaques sont classées en fonction de leur gravité pour les services web.

Bien que ce scanner effectue un peu plus d'analyses, il est très lent par rapport aux autres

outils disponibles sur le marché et il est également plus lent que SQLiX.

9.2 SQLmap :

Sqlmap est un scanner d'injection SQL construit en Python. L'objectif de cet outil est

de détecter les vulnérabilités d'injection SQL et de tirer profit de ces vulnérabilités sur les

applications web. Sqlmap détecte d'abord l'ensemble de la boucle dans votre site et utilise

ensuite une variété d'options pour effectuer une gestion extensive de la base de données,

énumérer les utilisateurs, vider le SGBD entier ou spécifique, récupérer l'utilisateur de la

session du SGBD et la base de données, lire un fichier spécifique sur la base de données

du SGBD.
61
le système de fichiers, etc. SQLmap est un peu plus rapide qu'acunetix web scanner mais

toujours plus lent que SQLiX, et il fait également très peu d'injection d'url dans la base de

données par rapport à SQLiX. Cet outil n'a pas non plus d'interface graphique.

9.3 Wapiti :

Wapiti est un outil en ligne de commande construit en Python et utilisant une

bibliothèque Python appelée lswww, qui permet d'explorer chaque page d'un site web

donné. Wapiti nous permet d'inspecter la sécurité de notre site web. Cet outil utilise

également la bibliothèque html Tidy pour nettoyer les pages html qui ne sont pas bien

formatées. Cette bibliothèque aide beaucoup à extraire des informations des pages web

html mal codées. En fait, il s'agit d'une analyse de boîte noire. Wapiti analyse toutes les

pages Web disponibles sur votre site et tente de trouver des scripts et des formulaires

dans lesquels il peut injecter des données afin de vérifier combien de types d'attaques sont

possibles sur le point d'injection sélectionné. Wapiti peut détecter les injections SQL et

XSS (Cross Site Scripting). Wapiti possède l'une des meilleures caractéristiques : il est

capable de différencier les vulnérabilités XSS temporaires et permanentes.

Il ne fournit pas d'interface graphique et vous devez l'utiliser à partir de l'interface de

ligne de commande. Comme cet outil n'a pas d'interface GUI, j'aimerais vous donner ici

une utilisation en ligne de commande.

Utilisation :

Wapiti-1.1.5 - Un scanner de vulnérabilités pour les applications web

Utilisation : python wapiti.py http://localhost/acu/indexacu.php [options] Les
options prises en charge sont les suivantes :
-s <url>
--start <url>
Pour spécifier une url par laquelle commencer
-x <url>
--exclure <url>
Pour exclure une url de l'analyse (par exemple les scripts de déconnexion)

62
 Vous pouvez également utiliser un joker (*)
Exemple : -x "http://localhost/acu/indexacu.php/?page=*&module=test"
ou -x http://server/base/admin/* pour exclure un répertoire.
-p <url_proxy>
--proxy <url_proxy>
Pour spécifier un proxy
Exemple : -p http://proxy:port/
-c <fichier_cookie>
--cookie <fichier_cookie>
Pour utiliser un cookie
-t <timeout>
--timeout <timeout>
Pour fixer le délai d'attente (en secondes)
-a <login%password>
--auth <login%password>
Définir les informations d'identification
pour l'authentification HTTP Ne
fonctionne pas avec Python 2.4
-r <nom_du_paramètre>
--remove <nom_du_paramètre>
Supprimer un paramètre des URL
-m <module>
--module <module>
Utiliser un ensemble prédéfini d'options
d'analyse/d'attaque GET_ALL : utiliser
uniquement les requêtes GET (pas de POST)
GET_XSS : attaques XSS uniquement avec la
méthode HTTP GET
POST_XSS : uniquement les attaques XSS avec la méthode HTTP POST
-u souligné
Utiliser des couleurs pour mettre en évidence les paramètres de vulnérabilité dans les résultats

9.4 Paros :

Paros est utilisé pour évaluer la sécurité des applications web. Paros est écrit en Java, et

les gens utilisent généralement cet outil pour évaluer la sécurité de leurs sites web et des

applications qu'ils fournissent sur le site web. Il est gratuit et, grâce à Paros, vous pouvez

exploiter et modifier toutes les données HTTP et HTTPS entre le client et le serveur, ainsi

que les champs de formulaire et les cookies. En bref, les fonctionnalités du scanner sont

les suivantes.

Selon l'analyse du serveur de la hiérarchie du site web, il vérifie la mauvaise

configuration du serveur. Cette fonction a été ajoutée parce que certains chemins d'URL

63
ne peuvent pas être reconnus et trouvés par le robot d'exploration. Les autres scanners

automatiques ne sont pas en mesure de le faire. Voici comment procéder

64
fonctionnalité Paros navigue sur le site et reconstruit la hiérarchie du site. Actuellement,

Paros effectue trois types de vérifications de la configuration du serveur. HTTP PUT,

Directory indexable, et fichier obsolète existant. Paros fournit également un fichier

journal, qui est créé lorsque toutes les requêtes HTTP et les réponses passent par Paros.

Dans le panneau de log, Paros affiche le format de la requête et de la réponse.

9.5 Pixy :

Pixy est le deuxième outil que j'ai trouvé sur le web et qui est écrit en Java. Pixy

effectue des analyses automatiques pour PHP 4 afin de détecter les injections SQL et les

attaques XSS. L'inconvénient majeur de Pixy est qu'il ne fonctionne que pour PHP 4 et

pas pour OOPHP 5. Pixy prend un fichier PHP entier en entrée et produit un rapport qui

montre la section de vulnérabilité possible dans ce fichier PHP avec quelques

informations supplémentaires pour comprendre l'attaque.

Lors de l'analyse de l'injection SQL, Pixy divise les résultats en trois catégories : non

contaminé, faiblement contaminé et fortement contaminé. Il fournit également un

graphique de dépendance et une valeur de dépendance. La valeur dépendante n'est rien

d'autre que la liste des points du programme dont dépend la valeur des variables.

9.6 Évaluation des performances de SQLiX par rapport à d'autres outils

commerciaux et open source : Les tableaux suivants sont des représentations tabulaires
de l'évaluation de la performance entre les outils et les cas de test qui montrent la
performance de chaque outil sur le site web correspondant.
site.

65
 Exécution UDF(utilis Non. de
Non. ateur Base de
Outils Temps type Langue GUI
d' définir la données
(minutes) d'attaq
injections fonction)
ues
SQLiX 2-3 300 OUI 2 Mon Perl Oui
SQL,
Oracle,
PSQL.
MSsql,
MS
Accès
Acunitix 25-30 NON 5 Tous ------- Oui
ci-dessus
Sqlmap 4-5 41 NON 3 Mon Python No
SQL, n
Oracle,
PSQL.
MSsql
Wapiti 7-8 XSS 90 NON 2 Sauf Python No
n
SQL 40 PSQL
Paros 8-10 40 NON 2 -- Java Oui
Pixy 4-5 -- NON 2 -- Java Oui

Figure 13 : Le tableau montre l'évaluation des performances de SQLiX par rapport à

d'autres outils.

66
 Temps
Outils d'exécution Site

(Procès-verbal)
SQLiX 2-3 http://jagdishhalde.hostrator.com/indexacu.php

Acunitix 10-20
Sqlmap 4-5
Wapiti 7-8
Paros 8-10
Pixy 4-5
Figure 14 : Cas de test pour http://jagdishhalde.hostrator.com/indexacu.php

Temps
Outils d'exécution Site

(Procès-verbal)
SQLiX 4-6 http://test.acunetix.com

Acunitix 25-30
Sqlmap 7-8
Wapiti 9-10
Paros 4-6
Pixy 25-30
Figure 15 : Cas de test pour http://test.acunetix.com

67
 Temps
Outils d'exécution Site

(Procès-verbal)
SQLiX 2-3 http://www.jeffgaroutte.com

Acunitix 8-10
Sqlmap 4-5
Wapiti 7-8
Paros 8-10
Pixy 4-5

Figure 16 : Cas de test pour http://www.jeffgaroutte.com

Exécution
Outils Temps Site
(minutes)
SQLiX 3-4 http://abhishek1984.zxq.net

Acunitix 10-12
Sqlmap 4-5
Wapiti 7-8
Paros 8-10
Pixy 4-5

Figure 17 : Cas de test pour http://abhishek1984.zxq.net

68
 Temps
Outils d'exécution Site

(Procès-verbal)
SQLiX 180- .... http://inderweb.com

Acunitix 90-120
Sqlmap 4-5/ Erreur
Wapiti N/A
Paros N/A
Pixy N/A

Figure 18 : Cas de test pour http://inderweb.com

Temps
Outils d'exécution Site

(Procès-verbal)
SQLiX 180 - .... http://www.surfindia.com

Acunitix 90-120/
ERREUR
Sqlmap N/A
Wapiti N/A
Paros N/A
Pixy N/A

Figure 19 : Cas de test pour http://www.surfindia.com

69
10.0 Voir les graphiques :

Voici les quatre graphiques que j'ai créés à partir de l'analyse des performances de SQLiX.

70
Figure 20 : graphiques de visualisation

71
11.0 Site de test de la vulnérabilité du Web SQLiX :

J'ai construit un site web qui est utilisé pour tester SQLiX. Ce site web fournit également

des informations sur les attaques de base par injection SQL. J'ai créé deux partitions sur

la page web principale, l'une fournit les composants disponibles sur le site et l'autre est

utilisée pour montrer le back-end du site. L'intention principale de cette structure est que

le troisième utilisateur puisse facilement voir comment l'outil SQLiX injecte les

différentes combinaisons d'URL données et tente de récupérer des informations non

autorisées à partir de l'arrière-plan. J'héberge ce site sur http:hostrator.com. Pour

héberger, il faut d'abord enregistrer le nom de domaine et télécharger tous les fichiers

frontaux ainsi que les scripts du serveur. J'importe également les schémas de base de

données et les données créées sur l'hôte local. Voici le lien pour le site web hébergé :

http://jagdishhalde.hostrator.com/indexacu.php

Voici quelques captures d'écran du site web.

ho

72
Figure 21 : Site de vulnérabilité de SQLiX Web avec page d'accueil du site source de
SQLiX.

73
 Figure 22 : Site de vulnérabilité de SQLiX Web avec la page d'accueil et le tableau
d'information de l'utilisateur final.

À partir de cette partition de la page web, on peut facilement voir le nombre d'injections
effectuées par SQLiX dans la base de données. Lors de l'analyse de cette page web
particulière, les entrées injectées liées à la base de données sont affichées sur le côté droit.

74
 Figure 23 : Site web de vulnérabilité SQLiX montrant les attaques de base par injection
SQL.

Cette page web donne un aperçu des attaques de base par injection SQL. Il y a quatre cas
que j'ai essayé de démontrer ici. Comment l'injection SQL se produit et quelles sont les
précautions à prendre lors de la construction d'un site web.

75
12.0 Cas de test

Voici deux sites web sur lesquels je fais fonctionner ma version améliorée de SQLiX-

1) http://test.acunetix.com

2) http://abhishek1984.zxq.net

Les captures d'écran suivantes montrent la différence entre l'analyse de chaque formulaire

du site web qui utilise la méthode http Post. La méthode http post n'est pas implémentée

dans la version originale de SQLiX.

Figure 24 : Cas de test pour l'analyse de http://test.acunetix.com à l'aide de SQLiX amélioré

76
Figure 25 : Cas de test pour le balayage de http://test.acunetix.com avec
résultat

77
 Figure 26 : Cas de test pour l'analyse de http://abhishek1984.zxq.net à l'aide de SQLiX

amélioré La capture d'écran ci-dessus montre clairement que SQLiX amélioré recherche des

formulaires et y injecte une injection SQL. Il utilise "PPPP" comme données fictives à insérer

dans chacun des champs du formulaire. Par conséquent, la version améliorée de SQLiX

effectue plus d'injections et tente de récupérer plus de données que la version originale de

SQLiX.

78
13.0 Conclusion

La plupart des applications web utilisent une couche intermédiaire pour accepter une

requête de l'utilisateur et extraire des informations sensibles de la base de données. La

plupart du temps, elles utilisent un langage de script pour construire la couche

intermédiaire. Pour violer la sécurité de la base de données, les pirates utilisent souvent

des techniques d'injection SQL. En général, l'attaquant tente d'embrouiller la technologie

de la couche intermédiaire en remodelant les requêtes SQL. Il est possible que l'attaquant

modifie les activités du programmeur à son avantage. Un certain nombre de méthodes

sont utilisées pour éviter les attaques par injection SQL au niveau de l'application, mais

aucune solution réalisable n'est encore disponible. Cet article couvre les techniques les

plus puissantes utilisées pour la prévention des injections SQL. Mes recherches m'ont

permis de conclure que les techniques automatisées de prévention, de détection et

d'enregistrement des attaques par injection SQL dans les procédures stockées sont

couramment utilisées et qu'il s'agit de méthodes concrètes. La méthode du contrôle

graphique est également adaptée aux petites bases de données.

SQLiX est l'un des meilleurs scanners de sécurité web pour trouver les vulnérabilités

d'injection SQL sur le site web, bien qu'il ne soit pas suffisant pour énumérer d'autres

types d'attaques web possibles. Il est très efficace en termes de vitesse, d'insertion du

nombre d'injections et d'injection de votre propre fonction. Vous pouvez juxtaposer les

cas de test représentés ci-dessus. J'ai amélioré cet outil en le dotant d'une interface

graphique, de la méthode HTTP POST, d'une fonction de remplissage automatique de

formulaire et d'attaques XSS. L'interface graphique permet à l'utilisateur novice d'essayer

toutes les combinaisons d'attaques sans avoir à se souvenir de toutes les options, et la

79
méthode HTTP POST augmente le nombre d'injections dans la base de données.

80
14.0 Travaux futurs :

Dans le cadre de travaux futurs, nous souhaitons évaluer les méthodes en utilisant

différents scripts d'applications web du domaine public afin d'atteindre une grande

précision dans les approches de prévention des injections SQL. L'intégration de SQLiX

avec nikto HTTP scanner, HTTP scanning proxies, et avec metasploit aidera à détecter

d'autres vulnérabilités web. La fonction de vidage de la base de données vénérable et du

schéma de la base de données a également été ajoutée.

Références

1. Wei, K., Muthuprasanna, M. et Suraj Kothari. (2006, 18 avril). Preventing SQL

injection attacks in stored procedures (Prévention des attaques par injection SQL dans les
procédures stockées). Software Engineering IEEE Conference. Consulté le 2 novembre
2007 sur http://ieeexplore.ieee.org

2. Thomas, Stephen, Williams et Laurie. (2007, 20 mai). Utilisation de la génération

automatisée de correctifs pour sécuriser les déclarations SQL. Software Engineering for
Secure Systems IEEE CNF. Consulté le 6 novembre 2007 sur http://ieeexplore.ieee.org

3. Merlo, Ettore, Letarte, Dominic, Antoniol & Giuliano. (21 mars 2007). Automated
Protection of PHP Applications Against SQL-injection Attacks (Protection automatisée
des applications PHP contre les attaques par injection SQL). Software Maintenance and
Reengineering, 11th European Conference IEEE CNF. Consulté le 9 novembre 2007 sur
http://ieeexplore.ieee.org

4. Wassermann Gary, Zhendong Su. (2007, juin). Sound and precise analysis of web
applications for injection vulnerabilities. ACM SIGPLAN conference on Programming
language design and implementation PLDI, 42 (6). Consulté le 7 novembre 2007 à
l'adresse suivante : http://portal.acm.org

5. Friedl's Steve Unixwiz.net Tech Tips. (2007). SQL Injection Attacks by Example
(Attaques d'injection SQL par l'exemple). Consulté le 1er novembre 2007 à l'adresse
suivante : http://www.unixwiz.net/techtips/sql-injection.html

6. Institut de technologie du Massachusetts. Web Application S ecurity MIT Security

Camp. Consulté le 1er novembre 2007 à l'adresse http://web.mit.edu/net-
security/Camp/2003/clambert-slides.pdf

81
7. Institut de technologie du Massachusetts. Sécurité des applications Web - Camp de
sécurité du MIT. Consulté le 1er novembre 2007 à l'adresse
http://groups.csmail.mit.edu/pag/reading- group/wasserman07injection.pdf

8. Gregory T. Buehrer, Bruce W. Weide et Paolo A. G. Sivilotti. The Ohio State

University Columbus, OH 43210 Using Parse Tree Validation to Prevent SQL Injection
Attacks. Consulté en janvier 2005, à l'adresse http://portal.acm.org

9. Zhendong Su, Gary Wassermann. Université de Californie, Davis. The Essence of

Command Injection Attacks inWeb Applications (L'essence des attaques par injection de
commandes dans les applications web). Consulté le 11 janvier 2006 sur le site
http://portal.acm.org

10. William G.J. Halfond, Alessandro Orso, et Panagiotis Manolios College of

Computing - Georgia Institute of Technology. Using Positive Tainting and Syntax-
Aware Evaluation to Counter SQL Injection Attacks (Utilisation de l'altération positive et
de l'évaluation consciente de la syntaxe pour contrer les attaques d'injection SQL).
Consulté le 11 novembre 2006 à l'adresse suivante : http://portal.acm.org

11. William G.J. Halfond et Alessandro Orso. College of Computing Georgia Institute of
Technology. Preventing SQL Injection Attacks Using AMNESIA (Prévention des
attaques par injection SQL à l'aide d'AMNESIA). Consulté le 28 mai 2007 à l'adresse
suivante : http://portal.acm.org

12. José Fonseca, Marco Vieira, Henrique Madeira. CISUC, Université de Coimbra
Département d'ingénierie informatique 3030 Coimbra - Portugal. Online Detection of
Malicious Data Access Using DBMS Auditing (Détection en ligne de l'accès malveillant
aux données à l'aide de l'audit du SGBD). Consulté le 20 mars 2008 sur le site
http://portal.acm.org

13. Frank S. Rietta 10630 Greenock Way Duluth, Georgia 30097. Application Layer
Intrusion Detection for SQL Injection (Détection d'intrusion au niveau de la couche
d'application pour l'injection SQL). Récupéré le 12 mars 2006 sur http://portal.acm.org

14. Martin Bravenboer, Eelco Dolstra, Eelco Visser, Université de technologie de Delft,
Pays-Bas. Preventing Injection Attacks with Syntax Embeddings A Host and Guest
Language Independent Approach. Consulté le 3 octobre 2007 sur le site
http://portal.acm.org

15. Yuji Kosuga, Kenji Kono, Miyuki Hanaoka Département des sciences de
l'information et de l'informatique Université de Keio. Sania : Syntactic and Semantic
Analysis for Automated Testing against SQL Injection. Consulté le 12 novembre 2007
sur le site de l'IEEE Computer Society. http://ieeexplore.ieee.org

16. Benjamin Livshits et U' lfar Erlingsson. Microsoft Research. Utilisation de cadres
de construction d'applications Web pour se protéger contre les attaques par injection de
code. Consulté le 14 juin 2007 sur http://ieeexplore.ieee.org
82
17. José Fonseca CISUC - Institut polytechnique de Guarda, Marco Vieira, Henrique
Madeira DEI/CISUC - Université de Coimbra. Testing and comparing web vulnerability
scanning tools for SQL injection and XSS attacks (Test et comparaison d'outils d'analyse
de la vulnérabilité des sites web pour les attaques par injection SQL et XSS). Consulté le
10 juillet 2007 à l'adresse suivante : http://ieeexplore.ieee.org

18. Hal Berghel. Hijacking the Web Consulté le 2 janvier 2002 sur le site
http://portal.acm.org

19. Engin Kirda, Christopher Kruegel, Giovanni Vigna et Nenad Jovanovic Université
technique de Vienne. Noxes : A Client-Side Solution for Mitigating Cross-Site Scripting
Attacks. Consulté le 5 juin 2006 sur le site http://portal.acm.org

20. http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project
21. http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project
22. http://search.cpan.org/~petdance/www-Mechanize-1.34/lib/www/Mechanize.pm
23. http://wapiti.sourceforge.net/
24. http://sqlmap.sourceforge.net/
25. http://www.acunetix.com/
26. http://en.wikipedia.org/wiki/Cross-site_scripting
27. http://en.wikipedia.org/wiki/SQL_injection
28. http://www.unixwiz.net/techtips/sql-injection.html
29. http://pixybox.seclab.tuwien.ac.at/pixy/index.php
30. http://www.parosproxy.ort/index.shtml

83