Injection SQL

Il existe plusieurs types d'injection SQL :

• la méthode blind based (associée à sa cousine la time based), qui permet de détourner la requête SQL en cours sur le système et d'injecter des morceaux qui vont retourner caractère par caractère ce que l'attaquant cherche à extraire de la base de données. La méthode blind based, ainsi que la time based, se basent sur la réponse du serveur : si la requête d'origine renvoie bien le même résultat qu'à l'origine (et indique donc que le caractère est valide) ou ne renvoie pas le même résultat (et indique donc que le caractère testé n'est pas le bon). La time based a pour seule différence qu'elle se base sur le temps de réponse du serveur plutôt que sur la réponse en elle-même ;
• la méthode error based, qui permet de détourner la requête SQL en cours sur le système et d'injecter des morceaux qui vont retourner champ par champ ce que l'on cherche à extraire de la base de données. Cette méthode profite d'une faiblesse des systèmes de base de données permettant de détourner un message d'erreur généré par le système de base de données et préalablement volontairement provoquée par l'injection SQL pour lui faire retourner une valeur précise récupérée en base de données ;
• la méthode union based, qui permet de détourner la requête SQL en cours sur le système et d'injecter des morceaux qui vont retourner un ensemble de données directement extraites de la base de données. Cette méthode profite de certaines méthodes afin de détourner entièrement le retour de la requête SQL d'origine afin de lui faire retourner en une seule requête un important volume de données, directement récupéré en base de données. Dans ses exemples les plus violents, il est possible de récupérer des tables entières de base de données en une ou deux requêtes, même si en général cette méthode retourne entre 10 et 100 lignes de la base de données par requête SQL détournée ;
• la méthode Stacked queries, la plus dangereuse de toutes. Profitant d'une erreur de configuration du serveur de base de données, cette méthode permet d'exécuter n'importe quelle requête SQL sur le système ciblé, ce qui ne se limite pas seulement à récupérer des données comme les 3 précédentes. En effet, quand ce type de requête n'est pas désactivé, il suffit d'injecter une autre requête SQL, et elle sera exécutée sans problème, qu'elle aille chercher des données, ou en modifier directement dans la base de données.

Considérons un site web dynamique (programmé en PHP dans cet exemple) qui dispose d'un système permettant aux utilisateurs possédant un nom d'utilisateur et un mot de passe valides de se connecter. Ce site utilise la requête SQL suivante pour identifier un utilisateur :

SELECT uid FROM Users WHERE name = '(nom)' AND password = '(mot de passe hashé)';

L'utilisateur Dupont souhaite se connecter avec son mot de passe « truc » hashé en MD5. La requête suivante est exécutée :

SELECT uid FROM Users WHERE name = 'Dupont' AND password = '45723a2af3788c4ff17f8d1114760e62';

SELECT uid FROM Users WHERE name = 'Dupont';--' AND password = '4e383a1918b432a9bb7702f086c56596e';

SELECT uid FROM Users WHERE name = 'Dupont';

SELECT uid FROM Users WHERE name = 'Dupont' AND password = '' or 1 --';

SELECT uid FROM Users WHERE name = 'Dupont\' -- ' AND password = '4e383a1918b432a9bb7702f086c56596e';

SELECT ... FROM ... WHERE numero_badge = $numero AND code_4_chiffre = $code;

Ces attaques peuvent être évitées de plusieurs façons :

1. Utiliser des procédures stockées, à la place du SQL dynamique. Les données entrées par l'utilisateur sont alors transmises comme paramètres, qui, s'ils sont correctement utilisés par la procédure (par exemple injectés dans une requête paramétrée), évitent l'injection ;
2. Vérifier de manière précise et exhaustive l'ensemble des données venant de l'utilisateur. On peut, par exemple, utiliser une expression rationnelle afin de valider qu'une donnée entrée par l'utilisateur est bien de la forme souhaitée, ou profiter de fonctions de transformation spécifiques au langage ;
3. Utiliser des comptes utilisateurs SQL à accès limité (en lecture-seule) quand cela est possible ;
4. Utiliser des requêtes SQL paramétrées (requêtes à trous envoyées au serveur SQL, serveur à qui l'on envoie par la suite les paramètres qui boucheront les trous), ainsi c'est le SGBD qui se charge d'échapper les caractères selon le type des paramètres.

• En février 2002, Jeremiah Jacks révèle une faille de sécurité sur le site de Guess.com exploitable par une attaque d’injection SQL et permettant d’obtenir les coordonnées de plus de 200 000 personnes y compris leurs numéros de cartes de crédit avec la date d’expiration[1].
• Le 1^er novembre 2005, un jeune pirate utilise l’injection SQL pour s’introduire dans le site d’information taïwanais consacrée à la sécurité informatique et s’empare des données de la base client[2].
• Le 29 mars 2006, un pirate s’attaque par une injection SQL au site officiel du tourisme indien appartenant au gouvernement[3].
• En janvier 2008, des dizaines de milliers de PC sont infectées par une injection SQL automatique exploitant une faille de sécurité de Microsoft SQL Server.
• Le 13 avril 2008 survient le vol de 10 597 numéros de sécurité sociale américains[4].
• Le 17 août 2009, le département de la justice américaine identifie l'américain Albert Gonzalez et deux russes comme les auteurs du vol de 130 millions de numéros de cartes de crédit grâce à une attaque par injection SQL. Les principales victimes sont la société de traitement des paiements par cartes Heartland Payment Systems, les chaînes de supermarché 7-eleven et Hannaford Brothers[5].
• Le 24 juillet 2010, des attaques par injection SQL simultanées de Japon et de Chine parviennent à pénétrer la société NeoBeat qui gère des supermarchés sur internet et volent 12 191 données de cartes bancaires.
• Le 8 novembre 2010, un pirate roumain appelé TinKode utilise une attaque par injection SQL pour paralyser le site de la Royal Navy en Angleterre[6] - [7].
• Le 11 avril 2011, l’ensemble du réseau Barracuda est victime d’une attaque par injection SQL. Identifiants et adresses emails des employés sont détournés[8].
• Le 1^er juin 2011, le groupe appelé LulzSec est accusé d’une attaque par injection SQL contre le site de Sony. Au moins 1 million de clients se font voler coupons, clés d’activation et mot de passe[9].
• En juillet 2012, Yahoo rapporte le vol de données de plus de 450,000 clients[10] - [11].
• En août 2013, Yahoo rapporte le vol de données de plus de 1 milliard de comptes[12] - [13].