Attaques par Injection SQL PDF

L’ATTAQUE PAR INJECTION DE CODE SQL 1. INTRODUCTION Les attaques par injection font référence à une large classe de vecteurs d’attaque. Dans une attaque par injection, un attaquant fournit des informations non fiables à un programme. Cette entrée est traitée par un interpréteur par le biais d’une...

L’ATTAQUE PAR INJECTION DE CODE SQL 1. INTRODUCTION Les attaques par injection font référence à une large classe de vecteurs d’attaque. Dans une attaque par injection, un attaquant fournit des informations non fiables à un programme. Cette entrée est traitée par un interpréteur par le biais d’une commande ou d’une requête, ce qui entraine une modification de l’exécution de ce programme. Les injections font partie des attaques les plus anciennes et les plus dangereuses visant les applications web. Ils peuvent entraîner : - Le vol de données, - La perte de données, - La modification des données, - Le déni de service, ainsi que la compromission de l’ensemble du système. La principale raison des vulnérabilités d’injection est généralement un contrôle insuffisant des entrées des utilisateurs. Parmi les attaques par injection les plus connus on peut citer les injections SQL (attaques SQLi) et les Cross-site Scripting (XSS), sont non seulement très dangereuses, mais aussi très répandues. Dans ce cours, nous détaillons l'attaque par injection SQL, communément appelée SQLIA (SQL Injection Attack). 2. L'ATTAQUE PAR INJECTION SQL L’attaque par injection SQL est un type d’attaque informatique courant qui affecte principalement les sites web exploitant des bases de données. Les attaques SQL visent donc le cœur d'une application web. De ce fait, si un serveur de base de données est attaqué où tombe en panne, c'est bel et bien tout le site qui s'en retrouve paralysé. Une personne malveillante peut ainsi lire, modifier ou supprimer des données arbitraires, auxquelles elle n'est pas forcément sensée avoir accès. - Elle consiste à modifier une requête SQL en cours par l’injection d’un morceau de requête non prévu, souvent par le biais d’un formulaire. L’attaquant peut ainsi accéder à la base de données, mais aussi modifier son contenu et donc compromettre la sécurité du système. - La vulnérabilité aux attaques par injection SQL est généralement due à une mauvaise gestion des données entrantes par le site web. - La nature du langage SQL ne fait pas de distinction réelle entre les instructions du programme « requête » et les données manipulées par le programme « requête ». De ce fait, si les données entrantes ne sont pas correctement contrôlées ou nettoyées, elles peuvent être utilisées pour manipuler les requêtes SQL et accéder à des informations sensibles, les modifier ou même détruire la base de données. 3. PRINCIPE DE L'ATTAQUE PAR INJECTION SQL La possibilité d 'accéder aux applications Web à distance multiplie les points d'attaque potentiels pour les pirates qui veulent attaquer ces applications ainsi que leurs bases de données. Le but essentiel du pirate est de changer la structure (ou la sémantique) des requêtes SQL pour qu’elles soient interprétées différemment de ce qui avait été prévu par le programmeur (Sun et al., 2007). Pour réaliser son objectif, le pirate injecte : - des caractères dangereux (' , / ,-, etc.) qui peuvent être injecté dans un champ d'entrée, - et des mots clés SQL (union, drop, etc.) dans les champs d'entrée. Dans le but de changer la structure d'une requête SQL dynamique pendant son exécution. Intuitivement, si le programmeur ne valide pas ou ne contrôle pas les entrées d'utilisateur avant de les employer dans des requêtes SQL dynamiques, alors l'attaque pourra réussir. Figure 1- L'attaque par injection SQL (Yassin, 2014). 4. LES MECANISMES D'INJECTION (Halfond et al., 2006), (Ngansop, s. d, 2009) Il existe trois mécanismes d'injection (Halfond et al., 2006), (Ngansop, s. d, 2009) permettant d'exécuter un code SQL malveillant sur les bases de données d'une application Web. 4.1 Injection dans les entrées d'utilisateur Si le code source d'une application Web contient des requêtes SQL construites avec les entrées d'utilisateur, un pirate peut facilement saisir des caractères dangereux dans ces entrées pour monter une SQLIA. Les entrées d'utilisateur constituent les points d'attaques les plus exploitables par les pirates et les moins détectables par les pare-feu. 4.2 Injection dans les témoins de connexion Les témoins de connexion (cookies) sont des fichiers placés sur le poste du client, associés à une application Web et contiennent des informations sur les préférences des utilisateurs. Comme les entrées d'utilisateur, les cookies peuvent être exploitables par un attaquant lorsque l'application Web stocke les données dans ces cookies sans les chiffrer. Les nouvelles applications web chiffrent les contenus de cookies pour contrer les attaques provenant de ces derniers. 4.3 Injection dans les variables du serveur La connexion entre le client et le serveur Web se rompt fréquemment, car HTTP (ou HTTPS) est un protocole déconnecté. Pour identifier les clients, le serveur crée des variables, appelées variables de serveur, contenant des informations concernant les clients et qui sont extraites à partir des entêtes http. Un pirate peut donc injecter ses propres valeurs dans l'entête http par l'URL pour perpétrer une SQLIA qui se déclenche automatiquement lorsque le serveur communique les valeurs des variables du serveur avec la base de données aux fins de statistique. 5. PRINCIPE de l’attaque par injection SQL L’attaque par injection SQL consiste à injecter du code SQL qui sera interprété par le moteur de base de données. Le code malicieux le plus répandu est d’ajouter une instruction pour faire en sorte que la requête sous-jacente soit toujours positive. Cela permet par exemple d’usurper une identité pour se connecter à une application Web, de rendre l’application inutilisable ou de supprimer toutes les données de la table visée, voire même de la base de données complète. L’attaque par injection SQL peut viser : 1. La disponibilité : (charge maximale du serveur de base de données, modification du mot de passe d’un utilisateur ou de l’administrateur de l’application web dans un UPDATE) ; 2. La confidentialité : obtention d’informations stockées dans la base, obtention d’un accès à un intranet sans autorisation ; 3. L’intégrité des données (modification ou suppression des données). 6. Exemples d’une attaque par injection SQL 6.1 Un premier exemple L’exemple suivant va interroger une table qui contient la liste des cartes bancaires enregistrées dans la base de données de l’application Web d’un site marchand. Le script de création de cette table est le suivant : Figure 2 - Script SQL de création de la table « comptes » Pour afficher le numéro de carte bancaire, l’utilisateur doit s’authentifier. La requête SQL suivante permet de vérifier que le couple utilisateur « user4 » /mot de passe du compte « eng111 » est correct et si tel est le cas renvoie le numéro de carte bancaire : Figure 3 - Requête SQL pour l’authentification et affichage du numéro de carte Le script PHP pour exploiter cette requête de façon dynamique avec les informations fournies par l’utilisateur est le suivant :  Figure 4 - Script PHP pour l’authentification et l’affichage du numéro de carte En remplissant le formulaire avec la valeur « ' OR 1=1 -- ' » pour le champ « nom » et n’importe quelle valeur pour le mot de passe, la requête qui sera envoyée à la base de données devient : Figure 5 - Requête SQL incluant du code frauduleux d’injection Ainsi la condition 1=1 est toujours vérifiée et le reste de la commande est mis en commentaire grâce à la chaîne de caractères « -- ». Cela permet donc de récupérer aléatoirement un numéro de carte. 6.2 Un deuxième exemple SELECT c3 FROM Users WHERE name = '(nom)' AND password = '(mot de passe hashé)'; L'utilisateur Salim souhaite se connecter avec son mot de passe « truc » hashé en MD5. La requête suivante est exécutée : SELECT c3 FROM Users WHERE name = ‘Salim' AND password = '45723a2af3788c4ff17f8d1114760e62'; Pour attaquer la requête, un hacker pourrait alors fournir les informations suivantes : - Utilisateur : Salim;-- - Mot de passe : n'importe lequel En utilisant la requête SQL suivante : SELECT c3 FROM Users WHERE name = 'Salim'; -- ' AND password = '4e383a1918b432a9bb7702f086c56596e'; 7. Listes des solutions Les meilleurs techniques à prendre en considération au moment de votre conception sont : 1. Supprimer tous les champs INPUT indésirables et de n’accepter que celle qui sont prévu ; 2. Toujours stocker les mots de passe dans la base de données du serveur sous forme crypté ; 3. Respectez le PRINCIPE DU MOINDRE PRIVILÈGE lorsque vous vous connectez à des bases de données ou tout autre système 4. Evitez les MESSAGES D’ERREURS détaillées, utiles aux attaquants 5. Utilisez des PROCÉDURES SQL STOCKÉES car elles sont généralement non vulnérables à l’injection SQL 6. Les caractères spéciaux : L’attaque citée précédemment repose principalement sur l’utilisation de caractères spécifiques qui permettent de mettre en commentaire des portions de code et d’insérer du code frauduleux. Il est cependant rare que l’application ait besoin d’accepter les caractères suivant. & ~ " # ' { } ( [ ] ( ) - | ` _ \ ^ @ \ * /. < > , ; : ! $