Etudes et analyse des contre-mesures des attaques par injection SQL

1. Protection des applications web contre les attaques par injection de code SQL (SQLIA)
Mohamed YASSIN - Université du Québec à Montréal
PRÉSENTATION
Les vulnérabilités des applications web L’attaque par injection du code SQL (SQLIA)
Les contre-mesures avancées de SQLIA Conclusion et travail future
Les attaques SQLIA constituent une menace très sérieuse pour la
sécurité des applications web.
Le SQLIA connaît une croissance plutôt qu’une régression.
Les techniques simples de protection demeurent inefficaces et
incomplètes et dépendent du compétence de développeurs.
Les contres mesures avancées sont efficaces mais ne sont pas
critiques et nécessitent une modification du code source et
une infrastructure additionnelle sur les applications Web existants.
L'idée de notre travail future est de trouver une solution de
détection et de prévention efficace , critique et capable d'être
complètement automatisée.
•Les vulnérabilités des applications web
•L’attaque par injection du code SQL
(SQLIA)
•Les conséquences et les menaces de
SQLIA
•Scénario de SQLIA
•Les techniques de SQLIA
•Les techniques simples de protection
•Les contre-mesures avancées de SQLIA
•Conclusion et travail future
L'attaque SQLIA consiste à injecter du code SQL malveillant
afin d'exécuter ce code sans autorisation sur la base de
données d'une application Web.
Souvent, le développeur construit les requêtes dynamiques
à partir des entrées de l'utilisateur des pages web.
Si les paramètres d'entrée ne sont pas filtrés et ne sont pas
validés avant de construire les requêtes, le hacker peut
introduire
un code SQL malveillant à partir de ces paramètres.
Les développeurs ne sont pas sensibles à ce type d'attaque à
cause de leurs confiances complètes aux contrôles d'accès et
leurs inexpériences en sécurité.
Les pare-feux et les IDS ne détectent pas les attaques SQLIA
provenant des entrées de l'utilisateur.
Les entrées de l'utilisateur : Les données saisies par
l’utilisateur via les pages Web sont envoyés à travers http et les
requêtes GET et POST. Si le développeur ne valide pas ces 2
fonctions avant de construire une requête alors ces fonctions
constituent une vulnérabilité.
Les variables de serveur: L’utilisation des protocoles de mode
déconnecté oblige le serveur de conserver sur la machine de
client les variables permettant d’identifier le client . Ces
variables peuvent créer une vulnérabilité.
Les cookies: sont des fichiers interprétés par le serveur mais
conservés (en clair ou encodées) sur le client. Comme le client
contrôle le stockage des cookies alors le hacker peut injecter du
code dans les contenus du cookie.
Les adresses web (URL) :Le hacker peut introduire certains
caractères devant la référence d’un site web pour provoquer des
messages d’erreur.
Utilisation normal
L'utilisateur saisit dans NomUsager "jean" et dans MotPasse
"123".
•Select * from TblUsagers
Where NomUsager=‘jean’ and MotPasse='123'
string strQuery="Select * from TblUsagers " _
Where NomUsager='" + txtNomUsager.text + "' and
MotPasse='" + txtMotPasse.text + "'"
Les conséquences et les menaces de SQLIA
Le projet OWASP (Open Web Application Security Project)
classe le SQLIA en première position parmi les dix risques de
sé curité applicatifs Web les plus critiques.
90% des applications web sont victimes de SQLIA.
La confiance des clients dans le commerce é lectronique
risque
de diminuer.
L'attaque SQLIA brise la confidentialité, l'authenticité , l'intégrité et
la disponibilité des applications web.
Le hacker peut en ré alisant un SQLIA:
•Modifier, intercepter et écraser les données.
•Voler et mettre à jour les profils et les privilèges d'utilisateurs.
•Contourner les contrô les d'accès .
•Prendre le contrô le du serveur.
•Réaliser un déni de service.
•Exécuter des commandes malveillantes.
Une application Web est accessible par un grand nombre
d'utilisateurs via internet, ce qui multiplie les points d'attaques.
Le hacker exploite ces points d’attaques pour perpétrer son attaque.
Scénario de SQLIA
Utilisation malicieux
Le hacker saisit dans NomUsager "admin’ OR 1=1 --" et dans
MotPasse "123".
•Select * from TblUsagers
Where NomUsager='admin' OR 1=1 --' and MotPasse='123'
La requête SQL est toujours satisfaisable et l'attaque a réussie.
Les techniques de SQLIA(1)
Tautologies: introduire le code SQL pour que la requête soit
toujours satisfaisable. L’attaque peut contourner l’authentification
et le contrôle d’accès.
Requête incorrecte: injecter certains paramètres pour amener le
serveur d’application à afficher des messages d’erreur contenant
des informations confidentielles.
• Le hacker saisit dans NomUsager (‘) et dans MotPass (123).
•Select * from TblUsagers
Where NomUsager =''' AND and MotPasse='123'
Msg 102, Level 15, State 1, Line 3
Incorrect syntax near '123'.
Msg 105, Level 15, State 1, Line 3
Unclosed quotation mark after the character string ''
Union de requêtes: réunir une requête avec la requête existante
afin de retourner toujours des résultats.
• Le hacker saisit dans NomUsager (‘ UNION select * from
TBLUSERS --) et dans MotPass (123).
• Select * from TblUsers Where NomUsager=‘ ’
UNION select * from TblUsers --' and MotPasse='123'
Les techniques simples de protection
Validation des entrées : consiste à valider tous les entrées de
l’utilisateur avec leurs types de données prédéfinis.
•Inefficace pour les entrées de type chaîne de caractères.
Filtration des entrées :rejeter les caractères illégaux (‘,-…)
et accepter les caractères autorisés.
•Pas de liste finale
•Faux positifs
•Compliquer l’utilisation (O’BRAIN).
Procédure stockée : L'utilisation des procédures stockées au
lieu des requêtes dynamiques.
Vérification de GET et POST : vérifier les paramètres de ces
deux fonctions avant de construire les requêtes.
Contrôle d'accès :utiliser des comptes utilisateurs SQL à accès
limité (en lecture-seule).
•Ne protège pas contre les tautologies.
Black box testing : tester un programme de l’extérieur en
identifiant tous les points d'accès d’une application Web et en
essayant les attaques SQLIA possibles.
Contrôle du code statique :
• JDBC-checker : Outil intégré dans JDBC qui permet de vérifier
statiquement le type de requête SQL dynamiquement produit
pour prévenir l’attaque qui sert à provoquer des erreurs de
syntaxe.
• Approche de Wassermann et Su : Analyse statique pour
vérifier que les requêtes SQL produites ne contiennent pas une
tautologie.
SQLrand : fournit un cadre qui permet aux développeurs de créer
des requêtes en utilisant des instructions randomisés au lieu des
mots clés SQL.
Analyse statique et dynamique combinée (AMNESIA)
Cette approche se déroule en 4 étapes:
•Identifier tous les points d’accès vulnérables (HotSpots)
•Générer un modèle pour chaque requête dynamique
•Intercepter chaque requête avant de l'envoyer à la BD
•Vérifier chaque requête contre le modèle crée statiquement.
Les techniques de SQLIA(2)
Requête "Piggy-backed": injecter une commande malveillante
pour s'exécuter sur le serveur.
•Le hacker saisit dans NomUsager (‘’ OR 1=1 ; Drop Table TblUsers
--) et dans MotPasse "123".
•Select * from TblUsers Where NomUsager='' OR 1=1 ;
Drop Table TblUsers --' and MotPasse='123‘
•L’intégrité des données (Update) .
•Déni de service (Shut Down).
Procédure stockée :Si le développeur exécute une requête
dynamiquement dans une procédure stockée alors le hacker peut
réaliser tous les types de SQLIA.
CREATE PROCEDURE ProcedureVulnerable
@NomUsager nvarchar(50), @MotPasse nvarchar(50)
AS
BEGIN
execute('Select * from TBLUsers
where NOM_USAGER='''+ @NomUsager + ''' and MotPasse=''' + @MotPasse + '''')
END
GO
Contre-mesures Modification
du code
source
Détection Prévention Infrastructure
additionnelle
Formation de
développeurs
AMNESIA Non Automatiqu
e
Automatique Aucun Aucun
Black Box
Testing
Non Automatiqu
e
Génération
des rapports
Aucun Aucun
JDBC-Checker Non Automatiqu
e
Suggestion
de code
Aucun Oui
SQLRand Oui Automatiqu
e
Automatique Proxy Oui
Tableau d'évaluation
Architecture SQL rand Architecture AMNESIA