Injection SQL

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Une injection SQL est un type d'exploitation d'une faille de sécurité d'une application interagissant avec une base de données, en injectant une requête SQL non prévue par le système et pouvant compromettre sa sécurité.

Exemple[modifier | modifier le code]

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';

Attaquer la requête[modifier | modifier le code]

Imaginons à présent que le script PHP exécutant cette requête ne vérifie pas les données entrantes pour garantir sa sécurité. Un hacker pourrait alors fournir les informations suivantes :

  • Utilisateur : Dupont' --
  • Mot de passe : n'importe lequel

La requête devient :

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

Les caractères -- marquent le début d'un commentaire en SQL. La requête est donc équivalente à :

SELECT uid FROM Users WHERE name = 'Dupont';

L'attaquant peut alors se connecter sous l'utilisateur Dupont avec n'importe quel mot de passe. Il s'agit d'une injection de SQL réussie, car l'attaquant est parvenu à injecter les caractères qu'il voulait pour modifier le comportement de la requête.

Supposons maintenant que l'attaquant veuille non pas tromper le script SQL sur le nom d'utilisateur, mais sur le mot de passe. Il pourra alors injecter le code suivant :

  • Utilisateur : Dupont
  • Mot de passe : ' or 1 --

L'apostrophe indique la fin de la zone de frappe de l'utilisateur, le code « or 1 » demande au script si 1 est vrai, or c'est toujours le cas, et -- indique le début d'un commentaire.

La requête devient alors :

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

Ainsi, le script programmé pour vérifier si ce que l'utilisateur tape est vrai, il verra que 1 est vrai, et l'attaquant sera connecté sous la session Dupont.

Solutions[modifier | modifier le code]

Échappement des caractères spéciaux[modifier | modifier le code]

La première solution consiste à échapper les caractères spéciaux contenus dans les chaînes de caractères entrées par l'utilisateur.

En PHP on peut utiliser pour cela la fonction mysqli_real_escape_string, qui transformera la chaîne ' -- en \' --. La requête deviendrait alors  :

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

L'apostrophe de fin de chaîne ayant été correctement dé-spécialisée en la faisant précéder d'un caractère « \ ».

L'échappement peut aussi se faire (suivant le SGBD utilisé) en doublant les apostrophes.

La marque de commentaire fera alors partie de la chaîne, et finalement le serveur SQL répondra qu'il n'y a aucune entrée dans la base de données correspondant à un utilisateur Dupont' -- avec ce mot de passe.

La fonction addslashes ne suffit pas pour stopper les injections via les variables numériques, qui ne sont pas encadrées d'apostrophes ou de guillemets dans les requêtes SQL. Exemple avec la requête :

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

qui réussit lorsque la variable $numero contient 0 or 1 --. Une précaution est d'utiliser la fonction ctype_digit pour vérifier les variables numériques des requêtes. On peut aussi forcer la transformation de la variable en nombre en la faisant précéder d'un transtypeur, comme (int) si on attend un entier (la chaîne 0 or 1 -- sera alors transformée en l'entier 0 et l'injection SQL échouera).

La fonction addslashes possède elle-même quelques failles sur certaines versions de PHP qui datent. De plus, elle échappe uniquement les caractères « \ », « NULL », « ' » et « " ». Il serait plus approprié d'utiliser la fonction mysqli_real_escape_string qui échappe justement les caractères spéciaux d'une commande SQL (NULL, \x1a, \n , \r , \, ', " et \x00).

Utilisation d'une requête préparée[modifier | modifier le code]

La seconde solution consiste à utiliser des requêtes préparées : dans ce cas, une compilation de la requête est réalisée avant d'y insérer les paramètres et de l'exécuter, ce qui empêche un éventuel code inséré dans les paramètres d'être interprété.

Comment éviter ces attaques[modifier | modifier le 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 PHP[modifier | modifier le code]

Les « magic quotes » étaient utilisées par défaut dans la configuration de PHP. Elles permettaient qu'un caractère d’échappement soit automatiquement placé devant les apostrophes et guillemets dangereux.

Certaines failles de sécurité et la disparition de magic_quotes_gpc dans PHP5.4 incitent à remplacer cette option par les solutions ci-dessus : la fonction mysqli_real_escape_string, les classes PHP Data Objectsetc.

Exemples[modifier | modifier le code]

  • 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 1er 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é social américains[4].
  • Le 17 août 2009, le département de la justice américaine identifie l'américain Albert Gonzales 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 Hearland 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 a 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 1er 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],[10].
  • En juillet 2012, Yahoo rapporte le vol de données de plus de 450 000 clients[11],[12][réf. incomplète].
  • Le 16 janvier 2014, Orange France est victime d’une attaque, les pirates dérobent noms, prénoms, adresses, emails et numéros de téléphone de 3 % de la clientèle de l’opérateur soit 800 000 personnes[13].

Notes et références[modifier | modifier le code]

  1. (en) « Guesswork Plagues Web Hole Reporting », SecurityFocus,‎ 6 mars 2002.
  2. (en) « WHID 2005-46: Teen uses SQL injection to break to a security magazine web site », Web Application Security Consortium,‎ 1er novembre 2005 (consulté en 1er décembre 2009).
  3. (en) « WHID 2006-27: SQL Injection in incredibleindia.org », Web Application Security Consortium,‎ 29 mars 2006 (consulté le 12 mars 2010).
  4. (en) Alex Papadimoulis, « Oklahoma Leaks Tens of Thousands of Social Security Numbers, Other Sensitive Data », The Daily WTF,‎ 15 avril 2008 (consulté le 16 mai 2008).
  5. (en) « US man 'stole 130m card numbers' », BBC,‎ 17 août 2009 (consulté en 17 août 2009).
  6. (en) Royal Navy website attacked by Romanian hacker, BBC News, 8-11-10[Quand ?], Accessed November 2010.
  7. (en) Sam Kiley, « Super Virus A Target For Cyber Terrorists »,‎ 25 novembre 2010 (consulté le 25 novembre 2010).
  8. (en) « Hacker breaks into Barracuda Networks database ».
  9. (en) « LulzSec hacks Sony Pictures, reveals 1m passwords unguarded », electronista.com,‎ 2 juin 2011.
  10. (en) Ridge Shan, « LulzSec Hacker Arrested, Group Leaks Sony Database », The Epoch Times,‎ 6 juin 2011.
  11. (en) Chenda Ngak. "Yahoo reportedly hacked: Is your account safe?", CBS News. 12 juillet 2012. Consulté le 16 juillet 2012.
  12. http://www.zdnet.com/450000-user-passwords-leaked-in-yahoo-breach-7000000772/
  13. [http:// http://www.clubic.com/connexion-internet/fai-orange-livebox/actualite-616274-donnees-800-000-clients-orange-piratees.html « Les données de 800 000 clients d'Orange piratées »].

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]