Injection SQL - SQL injection

Classification des vecteurs d'attaque par injection SQL en 2010
Une classification des vecteurs d'attaque par injection SQL à partir de 2010.

L'injection SQL est une technique d' injection de code utilisée pour attaquer les applications pilotées par les données, dans laquelle des instructions SQL malveillantes sont insérées dans un champ de saisie pour exécution (par exemple pour vider le contenu de la base de données vers l'attaquant). L'injection SQL doit exploiter une vulnérabilité de sécurité dans le logiciel d'une application, par exemple, lorsque l'entrée de l'utilisateur est soit incorrectement filtrée pour les caractères d' échappement littéraux de chaîne intégrés dans les instructions SQL ou que l'entrée de l'utilisateur n'est pas fortement typée et exécutée de manière inattendue. L'injection SQL est principalement connue comme un vecteur d' attaque pour les sites Web, mais peut être utilisée pour attaquer tout type de base de données SQL.

Les attaques par injection SQL permettent aux attaquants d' usurper l' identité, de falsifier des données existantes , de provoquer des problèmes de répudiation tels que l'annulation de transactions ou la modification de soldes, de permettre la divulgation complète de toutes les données du système, de détruire les données ou de les rendre autrement indisponibles, et de devenir administrateurs du serveur de base de données.

Dans une étude de 2012, il a été observé que l'application Web moyenne recevait quatre campagnes d'attaques par mois et que les détaillants recevaient deux fois plus d'attaques que les autres industries.

Histoire

Les premières discussions publiques sur l'injection SQL ont commencé à apparaître vers 1998 ; par exemple, un article de 1998 dans Phrack Magazine .

Former

L'injection SQL (SQLI) a été considérée comme l'une des 10 principales vulnérabilités des applications Web de 2007 et 2010 par l' Open Web Application Security Project . En 2013, SQLI a été classée première attaque dans le top 10 de l'OWASP. Il existe quatre sous-classes principales d'injection SQL :

  • Injection SQL + authentification insuffisante
  • Injection SQL + attaques DDoS
  • Injection SQL + piratage DNS
  • Injection SQL + XSS

Le Storm Worm est une représentation de Compounded SQLI.

Cette classification représente l'état de SQLI, respectant son évolution jusqu'en 2010, un affinement supplémentaire est en cours.

Implémentations techniques

Instructions SQL mal construites

Cette forme d'injection repose sur le fait que les instructions SQL se composent à la fois de données utilisées par l'instruction SQL et de commandes qui contrôlent la manière dont l'instruction SQL est exécutée. Par exemple, dans l'instruction SQL, la chaîne «  » est une donnée et le fragment est un exemple de commande (la valeur est également une donnée dans cet exemple). select * from person where name = 'susan' and age = 2susanand age = 22

L'injection SQL se produit lorsqu'une entrée utilisateur spécialement conçue est traitée par le programme récepteur d'une manière qui permet à l'entrée de quitter un contexte de données et d'entrer dans un contexte de commande. Cela permet à l'attaquant de modifier la structure de l'instruction SQL qui est exécutée.

À titre d'exemple simple, imaginez que les données «susan  » dans l'instruction ci-dessus ont été fournies par l'utilisateur. L'utilisateur a entré la chaîne " susan" (sans les apostrophes) dans un champ de saisie de texte de formulaire Web et le programme a utilisé des instructions de concaténation de chaînes pour former l'instruction SQL ci-dessus à partir des trois fragments , l'entrée utilisateur de " " et de . select * from person where name='susan' and age = 2

Imaginez maintenant qu'au lieu d'entrer ' susan' l'attaquant est entré . ' or 1=1; --

Le programme utilisera la même approche de concaténation de chaînes avec les 3 fragments de , l'entrée utilisateur de , et et construira l'instruction . De nombreuses bases de données ignoreront le texte après la chaîne '--' car cela dénote un commentaire. La structure de la commande SQL est maintenant et cela sélectionnera toutes les lignes de personne plutôt que celles nommées "susan" dont l'âge est de 2. L'attaquant a réussi à créer une chaîne de données qui sort du contexte de données et est entrée dans un contexte de commande. select * from person where name='' or 1=1; --' and age = 2select * from person where name='' or 1=1; -- and age = 2select * from person where name='' or 1=1;

Un exemple plus complexe est maintenant présenté.

Imaginez qu'un programme crée une instruction SQL à l'aide de la commande d'affectation de chaîne suivante :

var statement = "SELECT * FROM users WHERE name = '" + userName + "'";

Ce code SQL est conçu pour extraire les enregistrements du nom d'utilisateur spécifié de sa table d'utilisateurs. Cependant, si la variable "userName" est conçue d'une manière spécifique par un utilisateur malveillant, l'instruction SQL peut faire plus que ce que l'auteur du code avait prévu. Par exemple, définir la variable "userName" comme :

' OR '1'='1

ou en utilisant des commentaires pour même bloquer le reste de la requête (il existe trois types de commentaires SQL). Les trois lignes ont un espace à la fin :

' OR '1'='1' --
' OR '1'='1' {
' OR '1'='1' /* 

rend l'une des instructions SQL suivantes par le langage parent :

SELECT * FROM users WHERE name = '' OR '1'='1';
SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

Si ce code devait être utilisé dans la procédure d'authentification, cet exemple pourrait être utilisé pour forcer la sélection de chaque champ de données (*) de tous les utilisateurs plutôt que d'un nom d'utilisateur spécifique comme le codeur l'avait prévu, car l'évaluation de '1'= '1' est toujours vrai.

La valeur suivante de "userName" dans la déclaration ci-dessous entraînerait la suppression de la table "users" ainsi que la sélection de toutes les données de la table "userinfo" (révélant essentiellement les informations de chaque utilisateur), en utilisant une API qui autorise plusieurs déclarations :

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Cette entrée rend l'instruction SQL finale comme suit et spécifiée :

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Alors que la plupart des implémentations de serveur SQL autorisent l'exécution de plusieurs instructions avec un seul appel de cette manière, certaines API SQL telles que la fonction PHPmysql_query() ne le permettent pas pour des raisons de sécurité. Cela empêche les attaquants d'injecter des requêtes entièrement séparées, mais ne les empêche pas de modifier les requêtes.

Injection SQL aveugle

L'injection SQL aveugle est utilisée lorsqu'une application Web est vulnérable à une injection SQL mais que les résultats de l'injection ne sont pas visibles pour l'attaquant. La page avec la vulnérabilité peut ne pas être celle qui affiche des données mais s'affichera différemment selon les résultats d'une instruction logique injectée dans l'instruction SQL légitime appelée pour cette page. Ce type d'attaque a traditionnellement été considéré comme prenant beaucoup de temps car une nouvelle instruction devait être élaborée pour chaque bit récupéré, et selon sa structure, l'attaque peut consister en de nombreuses requêtes infructueuses. Les progrès récents ont permis à chaque requête de récupérer plusieurs bits, sans requêtes infructueuses, permettant une extraction plus cohérente et efficace. Il existe plusieurs outils qui peuvent automatiser ces attaques une fois que l'emplacement de la vulnérabilité et les informations sur la cible ont été établis.

Réponses conditionnelles

Un type d'injection SQL aveugle force la base de données à évaluer une instruction logique sur un écran d'application ordinaire. Par exemple, un site Web de critique de livre utilise une chaîne de requête pour déterminer quelle critique de livre afficher. Ainsi, l' URL https://books.example.com/review?id=5 obligerait le serveur à exécuter la requête

SELECT * FROM bookreviews WHERE ID = '5';

à partir de laquelle il remplirait la page de révision avec les données de la révision avec l' ID 5, stockées dans la table bookreviews. La requête se passe complètement sur le serveur ; l'utilisateur ne connaît pas les noms de la base de données, de la table ou des champs, ni la chaîne de requête. L'utilisateur voit seulement que l'URL ci-dessus renvoie une critique de livre. Un pirate peut charger les URL et , ce qui peut entraîner des requêtes https://books.example.com/review?id=5 OR 1=1https://books.example.com/review?id=5 AND 1=2

SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

respectivement. Si l'avis d'origine se charge avec l'URL "1=1" et qu'une page vierge ou d'erreur est renvoyée à partir de l'URL "1=2", et que la page renvoyée n'a pas été créée pour alerter l'utilisateur que l'entrée n'est pas valide, ou dans d'autres mots, a été intercepté par un script de test d'entrée, le site est probablement vulnérable à une attaque par injection SQL car la requête aura probablement réussi dans les deux cas. Le pirate peut continuer avec cette chaîne de requête conçue pour révéler le numéro de version de MySQL exécuté sur le serveur : , ce qui afficherait la critique du livre sur un serveur exécutant MySQL 4 et une page vierge ou d'erreur sinon. Le pirate peut continuer à utiliser du code dans des chaînes de requête pour atteindre son objectif directement, ou pour glaner plus d'informations sur le serveur dans l'espoir de découvrir une autre voie d'attaque. https://books.example.com/review?id=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4

Injection SQL de second ordre

L'injection SQL de second ordre se produit lorsque les valeurs soumises contiennent des commandes malveillantes qui sont stockées plutôt qu'exécutées immédiatement. Dans certains cas, l'application peut coder correctement une instruction SQL et la stocker en tant que SQL valide. Ensuite, une autre partie de cette application sans contrôles pour se protéger contre l'injection SQL peut exécuter cette instruction SQL stockée. Cette attaque nécessite une meilleure connaissance de la façon dont les valeurs soumises sont utilisées ultérieurement. Les scanners de sécurité d'applications Web automatisés ne détecteraient pas facilement ce type d'injection SQL et il peut être nécessaire de demander manuellement où vérifier les preuves qu'il est tenté.

Atténuation

Une injection SQL est une attaque bien connue et facilement prévenue par des mesures simples. Après une apparente attaque par injection SQL sur TalkTalk en 2015, la BBC a rapporté que les experts en sécurité étaient stupéfaits qu'une si grande entreprise y soit vulnérable.

Mappeurs relationnels d'objets

Les développeurs peuvent utiliser des frameworks ORM tels que Hibernate pour créer des requêtes de base de données de manière sûre et conviviale pour les développeurs. Étant donné que les requêtes de base de données ne sont plus construites sous forme de chaînes, il n'y a aucun risque de vulnérabilité d'injection.

Pare-feu d'applications Web

Alors que les produits WAF tels que ModSecurity CRS ne peuvent pas empêcher les vulnérabilités d'injection SQL de s'infiltrer dans une base de code, ils peuvent rendre la découverte et l'exploitation beaucoup plus difficiles pour un attaquant.

Détection

Le filtrage par injection SQL fonctionne de la même manière que les filtres anti-spam des e-mails. Les pare-feu de base de données détectent les injections SQL en fonction du nombre de requêtes invalides de l'hôte, de la présence de blocs OR et UNION à l'intérieur de la requête ou d'autres caractéristiques.

Instructions paramétrées

Avec la plupart des plates-formes de développement, des instructions paramétrées qui fonctionnent avec des paramètres peuvent être utilisées (parfois appelées espaces réservés ou variables de liaison ) au lieu d'intégrer l'entrée utilisateur dans l'instruction. Un espace réservé ne peut stocker qu'une valeur du type donné et non un fragment SQL arbitraire. Par conséquent, l'injection SQL serait simplement traitée comme une valeur de paramètre étrange (et probablement invalide). Dans de nombreux cas, l'instruction SQL est fixe et chaque paramètre est un scalaire , pas une table . L'entrée utilisateur est ensuite affectée (liée) à un paramètre.

En termes simples, l'utilisation de requêtes paramétrées peut définitivement empêcher l'injection SQL. Cela signifie principalement que vos variables ne sont pas des chaînes de requête qui accepteraient des entrées SQL arbitraires, cependant, certains paramètres de types donnés sont absolument nécessaires. Les requêtes paramétrées nécessitent que le développeur définisse tout le code. Par conséquent, sans requêtes paramétrées, n'importe qui pourrait mettre n'importe quel type de code SQL dans le champ et faire effacer la base de données. Mais si les paramètres étaient définis sur '@username', la personne ne pourrait alors saisir qu'un nom d'utilisateur sans aucun type de code.

Application au niveau du codage

L'utilisation de bibliothèques de mappage objet-relationnel évite d'avoir à écrire du code SQL. La bibliothèque ORM générera en effet des instructions SQL paramétrées à partir de code orienté objet.

S'échapper

Un moyen populaire, bien que sujet aux erreurs et finalement voué à l'échec, pour empêcher les injections est d'essayer d'échapper à tous les caractères qui ont une signification particulière dans SQL. Le manuel d'un SGBD SQL explique quels caractères ont une signification particulière, ce qui permet de créer une liste noire complète des caractères à traduire. Par exemple, chaque occurrence d'un guillemet simple ( ') dans un paramètre doit être remplacée par deux guillemets simples ( '') pour former un littéral de chaîne SQL valide. Par exemple, en PHP, il est habituel d'échapper les paramètres à l'aide de la fonction mysqli_real_escape_string();avant d'envoyer la requête SQL :

$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                  $mysqli->real_escape_string($username),
                  $mysqli->real_escape_string($password));
$mysqli->query($query);

Cette fonction ajoute des barres obliques inverses aux caractères suivants : \x00, \n, \r, \, ', "et \x1a. Cette fonction est normalement utilisée pour sécuriser les données avant d'envoyer une requête à MySQL .
PHP a des fonctions similaires pour d'autres systèmes de base de données tels que pg_escape_string() pour PostgreSQL . La fonction addslashes(string $str)fonctionne pour les caractères d'échappement et est utilisée en particulier pour interroger les bases de données qui n'ont pas de fonctions d'échappement en PHP. Il retourne une chaîne avec barre oblique inverse avant les caractères qui doivent être échappé dans les requêtes de base de données, etc. Ces caractères sont guillemets simples ( '), guillemet ( "), barre oblique inverse (\) et NUL (l'octet NULL).
Passant routinière des chaînes échappées to SQL est sujette aux erreurs car il est facile d'oublier d'échapper à une chaîne donnée. La création d'une couche transparente pour sécuriser l'entrée peut réduire cette propension aux erreurs, voire l'éliminer complètement.

Vérification de motif

Entier, flottant ou booléen, les paramètres de chaîne peuvent être vérifiés si leur valeur est une représentation valide pour le type donné. Les chaînes qui doivent suivre un modèle strict (date, UUID, alphanumérique uniquement, etc.) peuvent être vérifiées si elles correspondent à ce modèle.

Autorisations de base de données

Limiter les autorisations sur la connexion à la base de données utilisée par l'application Web uniquement à ce qui est nécessaire peut aider à réduire l'efficacité des attaques par injection SQL qui exploitent les bogues de l'application Web.

Par exemple, sur Microsoft SQL Server , une connexion à une base de données pourrait être empêchée de sélectionner certaines des tables système, ce qui limiterait les exploits qui tentent d'insérer du JavaScript dans toutes les colonnes de texte de la base de données.

deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

Exemples

  • En février 2002, Jeremiah Jacks a découvert que Guess.com était vulnérable à une attaque par injection SQL, permettant à toute personne capable de construire une URL correctement conçue d'extraire plus de 200 000 noms, numéros de carte de crédit et dates d'expiration dans la base de données clients du site.
  • Le 1er novembre 2005, un adolescent pirate a utilisé l'injection SQL pour pénétrer le site d'un magazine taïwanais de sécurité de l'information du groupe Tech Target et voler les informations des clients.
  • Le 13 janvier 2006, des criminels informatiques russes ont fait irruption sur un site Web du gouvernement de Rhode Island et auraient volé des données de carte de crédit à des personnes ayant fait des affaires en ligne avec des agences de l'État.
  • Le 29 Mars 2006, un pirate informatique a découvert une faille d'injection SQL dans un fonctionnaire du gouvernement indien du tourisme site.
  • Le 29 juin 2007, un criminel informatique a défiguré le site Web de Microsoft UK en utilisant l'injection SQL. Le site Web britannique The Register a cité un porte-parole de Microsoft reconnaissant le problème.
  • Le 19 septembre 2007 et le 26 janvier 2009, le groupe de hackers turc "m0sted" a utilisé l'injection SQL pour exploiter le serveur SQL de Microsoft afin de pirater des serveurs Web appartenant respectivement à McAlester Army Ammunition Plant et au US Army Corps of Engineers .
  • En janvier 2008, des dizaines de milliers de PC ont été infectés par une attaque d'injection SQL automatisée qui a exploité une vulnérabilité dans le code d'application qui utilise Microsoft SQL Server comme magasin de base de données.
  • En juillet 2008, le site malaisien de Kaspersky a été piraté par le groupe de hackers "m0sted" à l'aide d'une injection SQL.
  • Le 13 avril 2008, le registre des délinquants sexuels et violents de l' Oklahoma a fermé son site Web pour « entretien courant » après avoir été informé que 10 597 numéros de sécurité sociale appartenant à des délinquants sexuels avaient été téléchargés via une attaque par injection SQL.
  • En mai 2008, une batterie de serveurs à l' intérieur de la Chine a utilisé automatisé des requêtes à moteur de recherche de Google pour identifier les serveurs SQL sites qui étaient vulnérables à l'attaque d'un outil d'injection SQL automatisée.
  • En 2008, au moins d'avril à août, une série d'attaques a commencé à exploiter les vulnérabilités d'injection SQL du serveur Web IIS de Microsoft et du serveur de base de données SQL Server . L'attaque ne nécessite pas de deviner le nom d'une table ou d'une colonne et corrompt toutes les colonnes de texte de toutes les tables en une seule requête. Une chaîne HTML qui fait référence à un fichier JavaScript malveillant est ajoutée à chaque valeur. Lorsque cette valeur de base de données est ensuite affichée à un visiteur du site Web, le script tente plusieurs approches pour prendre le contrôle du système d'un visiteur. Le nombre de pages web exploitées est estimé à 500 000.
  • Le 17 août 2009, le ministère de la Justice des États-Unis a inculpé un citoyen américain, Albert Gonzalez , et deux Russes anonymes du vol de 130 millions de numéros de carte de crédit à l'aide d'une attaque par injection SQL. Dans ce qui aurait été "le plus grand cas d' usurpation d' identité de l'histoire des États-Unis", l'homme a volé les cartes d'un certain nombre de victimes d'entreprises après avoir étudié leurs systèmes de traitement des paiements . Parmi les entreprises touchées figuraient le processeur de cartes de crédit Heartland Payment Systems , la chaîne de magasins de proximité 7-Eleven et la chaîne de supermarchés Hannaford Brothers .
  • En décembre 2009, un attaquant a piraté une base de données en texte clair RockYou contenant les noms d'utilisateur et mots de passe non cryptés d'environ 32 millions d'utilisateurs à l'aide d'une attaque par injection SQL.
  • En juillet 2010, un chercheur en sécurité sud-américain qui s'appelle « Ch Russo » a obtenu des informations sensibles sur les utilisateurs du populaire site BitTorrent The Pirate Bay . Il a eu accès au panneau de contrôle administratif du site et a exploité une vulnérabilité d'injection SQL qui lui a permis de collecter des informations de compte d'utilisateur, notamment des adresses IP , des hachages de mot de passe MD5 et des enregistrements de torrents téléchargés par des utilisateurs individuels.
  • Du 24 au 26 juillet 2010, des attaquants japonais et chinois ont utilisé une injection SQL pour accéder aux données de carte de crédit des clients de Neo Beat, une société basée à Osaka qui gère un grand site de supermarché en ligne. L'attaque a également touché sept partenaires commerciaux, dont les chaînes de supermarchés Izumiya Co, Maruetsu Inc et Ryukyu Jusco Co. Le vol de données a touché 12 191 clients. Au 14 août 2010, il a été signalé qu'il y avait eu plus de 300 cas d'informations de carte de crédit utilisées par des tiers pour acheter des biens et des services en Chine.
  • Le 19 septembre, lors des élections générales suédoises de 2010, un électeur a tenté une injection de code à la main en écrivant des commandes SQL dans le cadre d'un vote écrit .
  • Le 8 novembre 2010, le site Web de la Royal Navy britannique a été compromis par un pirate informatique roumain nommé TinKode à l' aide d'une injection SQL.
  • Le 5 février 2011, HBGary , une entreprise de sécurité technologique, a été cambriolée par LulzSec à l' aide d'une injection SQL dans leur site Web géré par CMS.
  • Le 27 mars 2011, www.mysql.com, la page d'accueil officielle de MySQL , a été compromis par un pirate utilisant l'injection aveugle SQL
  • Le 11 avril 2011, Barracuda Networks a été compromis à l'aide d'une faille d'injection SQL. Les adresses e-mail et les noms d'utilisateur des employés figuraient parmi les informations obtenues.
  • Sur une période de 4 heures, le 27 avril 2011, une attaque automatisée par injection SQL s'est produite sur le site Web de Broadband Reports qui a pu extraire 8 % des paires nom d'utilisateur/mot de passe : 8 000 comptes aléatoires sur les 9 000 comptes actifs et 90 000 comptes anciens ou inactifs.
  • Le 1er juin 2011, des « hacktivistes » du groupe LulzSec ont été accusés d'avoir utilisé SQLI pour voler des coupons , des clés de téléchargement et des mots de passe stockés en clair sur le site Web de Sony , accédant aux informations personnelles d'un million d'utilisateurs.
  • En juin 2011, PBS a été piraté par LulzSec, très probablement à l'aide d'une injection SQL ; le processus complet utilisé par les pirates pour exécuter des injections SQL a été décrit dans ce blog Imperva .
  • En mai 2012, le site Web de Wurm Online , un jeu en ligne massivement multijoueur , a été fermé à cause d'une injection SQL pendant la mise à jour du site.
  • En juillet 2012, un groupe de pirates informatiques aurait volé 450 000 identifiants de connexion à Yahoo! . Les identifiants étaient stockés en texte brut et auraient été extraits d'un sous - domaine Yahoo , Yahoo! Des voix . Le groupe a violé la sécurité de Yahoo en utilisant une " technique d'injection SQL basée sur l' union ".
  • Le 1er octobre 2012, un groupe de hackers appelé "Team GhostShell" a publié les dossiers personnels des étudiants, des professeurs, des employés et des anciens de 53 universités, dont Harvard , Princeton , Stanford , Cornell , Johns Hopkins et l' Université de Zurich sur pastebin. com . Les pirates ont affirmé qu'ils essayaient de "sensibiliser aux changements apportés dans l'éducation d'aujourd'hui", déplorant l'évolution des lois sur l'éducation en Europe et l'augmentation des frais de scolarité aux États-Unis .
  • En février 2013, un groupe de pirates maldiviens a piraté le site Web "UN-Maldives" à l'aide de l'injection SQL.
  • Le 27 juin 2013, le groupe de hackers " RedHack " a pénétré le site d'administration d'Istanbul. Ils ont affirmé qu'ils avaient pu effacer les dettes des gens envers les compagnies d'eau, de gaz, d'Internet, d'électricité et de téléphone. De plus, ils ont publié le nom d'utilisateur et le mot de passe de l'administrateur pour que les autres citoyens puissent se connecter et effacer leurs dettes tôt le matin. Ils ont annoncé la nouvelle sur Twitter.
  • Le 4 novembre 2013, le groupe hacktiviste « RaptorSwag » aurait compromis 71 bases de données du gouvernement chinois en utilisant une attaque par injection SQL contre la Chambre chinoise de commerce international. Les données divulguées ont été publiées publiquement en coopération avec Anonymous .
  • Le 2 février 2014, AVS TV avait 40 000 comptes divulgués par un groupe de piratage appelé @deletesec
  • Le 21 février 2014, le Forum des Nations Unies sur la gouvernance de l'Internet a divulgué 3 215 détails de compte.
  • Le 21 février 2014, des pirates d'un groupe appelé @deletesec ont piraté Spirol International après avoir prétendument menacé de faire arrêter les pirates pour avoir signalé la faille de sécurité. 70 000 détails d'utilisateurs ont été exposés au cours de ce conflit.
  • Le 7 mars 2014, des responsables de l'Université Johns Hopkins ont annoncé publiquement que leurs serveurs d'ingénierie biomédicale avaient été victimes d'une attaque par injection SQL menée par un pirate anonyme nommé « Hooky » et aligné avec le groupe hacktiviste « RaptorSwag ». Les pirates ont compromis les données personnelles de 878 étudiants et membres du personnel, publiant un communiqué de presse et les données divulguées sur Internet.
  • En août 2014, la société de sécurité informatique basée à Milwaukee , Hold Security, a révélé qu'elle avait découvert un vol d'informations confidentielles sur près de 420 000 sites Web grâce à des injections SQL. Le New York Times a confirmé cette conclusion en embauchant un expert en sécurité pour vérifier la réclamation.
  • En octobre 2015, une attaque par injection SQL a été utilisée pour voler les données personnelles de 156 959 clients des serveurs de la société de télécommunications britannique TalkTalk , exploitant une vulnérabilité dans un ancien portail Web.
  • En août 2020, une attaque par injection SQL a été utilisée pour accéder à des informations sur les intérêts romantiques de nombreux étudiants de Stanford , en raison de normes de désinfection des données non sécurisées de la part de Link, une start-up fondée sur le campus par Ishan Gandhi.
  • Début 2021, 70 gigaoctets de données ont été exfiltrés du site Web d'extrême droite Gab via une attaque par injection SQL. La vulnérabilité a été introduite dans la base de code de Gab par Fosco Marotto, le CTO de Gab . Une deuxième attaque contre Gab a été lancée la semaine suivante à l'aide de jetons OAuth2 volés lors de la première attaque.

Dans la culture populaire

  • La connexion non autorisée à des sites Web au moyen d'une injection SQL constitue la base de l'une des intrigues secondaires du roman de 2012 de JK Rowling , The Casual Vacancy .
  • Un dessin animé xkcd de 2007 impliquait un personnage de Robert'); DROP TABLE étudiants;-- nommés pour effectuer une injection SQL. À la suite de ce dessin animé, l'injection SQL est parfois appelée de manière informelle « tables Bobby ».
  • En 2014, un particulier en Pologne a légalement rebaptisé son entreprise en Dariusz Jakubowski x' ; utilisateurs DROP TABLE ; SELECT '1 pour tenter de perturber le fonctionnement des robots de collecte des spammeurs .
  • Le jeu Hacknet de 2015 a un programme de piratage appelé SQL_MemCorrupt. Il est décrit comme l'injection d'une entrée de table qui provoque une erreur de corruption dans une base de données SQL, puis interroge ladite table, provoquant un plantage de la base de données SQL et un vidage de mémoire.
  • Dans l' épisode 2019 Star Trek: Discovery Si la mémoire sert, le commandant Airiam a découvert qu'une sonde qui avait attaqué une banque de données sur l'une des navettes du navire avait effectué un certain nombre d'injections SQL, mais qu'elle n'avait trouvé aucun fichier compromis.

Voir également

Les références

Liens externes