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 normalL'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 malicieuxLe 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 3Incorrect syntax near '123'.Msg 105, Level 15, State 1, Line 3Unclosed 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)ASBEGINexecute('Select * from TBLUsers where NOM_USAGER='''+ @NomUsager + ''' and MotPasse=''' + @MotPasse + '''')ENDGO

Contre-mesures Modification du code source

Détection Prévention Infrastructureadditionnelle

Formation de développeurs

AMNESIA Non Automatique

Automatique Aucun Aucun

Black Box Testing

Non Automatique

Générationdes rapports

Aucun Aucun

JDBC-Checker Non Automatique

Suggestion de code

Aucun Oui

SQLRand Oui Automatique

Automatique Proxy Oui

Tableau d'évaluation

Architecture SQL rand Architecture AMNESIA