Applications, sites et API
Particuliers et entreprisesInjection SQL
SQL injection — SQLi
Une entrée mal traitée modifie une requête vers la base de données.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Un formulaire de recherche sert normalement à retrouver une commande. Si le site confond le texte saisi avec des instructions pour sa base de données, une personne peut obtenir des résultats qui ne lui appartiennent pas.
Comment cela fonctionne
Une injection SQL détourne la façon dont un service interroge sa base de données. Le problème se situe dans la construction de la requête, pas dans la présence d’un caractère « interdit » à lui seul. L’attaquant cherche à faire traiter son entrée comme une partie des instructions. Il peut parfois lire, modifier ou supprimer des informations. Un visiteur ordinaire n’a pas à réparer ce défaut : c’est au développeur et à l’exploitant du service de le corriger.
- Une valeur arrive au site
Recherche, formulaire ou autre entrée.
- Elle devient une instruction
La requête est construite sans séparation sûre.
- La base répond autrement
Lecture ou modification non autorisée.
Ce que vous pouvez faire
Vos premiers réflexes
Vous n’avez pas à réparer la base de données du site. Si une recherche montre des documents d’autrui, arrêtez la consultation et signalez au service la page et l’heure.
Si vous êtes responsable du service ou de l’organisation
Développeurs : passez les valeurs par les paramètres du pilote SQL et vérifiez les droits de chaque utilisateur. Limitez aussi le compte de base de données de l’application.
Masquer les messages d’erreur ne corrige pas une injection SQL.
À vous de décider
Une recherche affiche la facture d’un autre client. Faut-il essayer d’autres recherches pour prouver le problème ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Arrêtez la consultation et signalez la page, l’heure et votre action au responsable, sans diffuser les documents d’autrui. Le service doit vérifier la cause : une donnée affichée à tort est un problème, mais ne suffit pas à identifier une injection SQL plutôt qu’un autre défaut d’accès.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Une recherche de factures renvoie les données d’un autre client
Une injection SQL apparaît lorsque l’application assemble une requête en y insérant directement une valeur reçue du navigateur. La base peut alors interpréter cette valeur comme une instruction. Dans le cas présenté, une recherche effectuée par le client A renvoie aussi une facture du client B : le filtre qui devait séparer leurs données a été contourné.
Les lignes portant req=r41 permettent de suivre la même requête du serveur web jusqu’à la réponse. Le champ returned_tenants=A,B révèle ici la fuite entre clients. Ce champ a été ajouté par l’application ; il n’existe pas dans tous les journaux. Sans lui, status=200 indique seulement que le serveur a répondu, sans préciser quelles données il a livrées.
La correction consiste à séparer la structure SQL des valeurs transmises, avec les paramètres du pilote de base de données. Il faut conserver le contrôle des droits du client connecté. Les noms de colonnes et les options de tri demandent un traitement différent : l’application doit les choisir dans une liste définie à l’avance. Vérifier aussi les exports, les tâches différées et les droits du compte SQL, car ils peuvent utiliser le même défaut.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Recherche + session du client A
Client de test vers API factures
Trace r41 / identité serveur
- Action
Vulnérable : SQL concaténé
API factures vers Pilote SQL
Trace Version du code
- Action
Condition SQL détournée
Pilote SQL vers SGBD
Trace Audit des lectures
- Réponse
Factures A et B
SGBD vers API factures
Trace db_rows / portée
- Réponse
Le client A reçoit aussi des factures du client B
API factures vers Client de test
- Action
Corrigé : SQL fixe + valeurs liées
API factures vers Pilote SQL
Trace Test de non-régression
- Action
Même entrée traitée comme donnée
Pilote SQL vers SGBD
- Réponse
Aucune correspondance
SGBD vers API factures
Comment repérer cette attaque
Indices à rechercher
- Des erreurs de base de données apparaissent dans l’interface.
- Des requêtes inhabituelles provoquent des réponses ou temps de traitement anormaux.
- Des lectures ou modifications ne correspondent pas aux actions autorisées.
Rechercher les réponses qui contiennent des données d’un autre client, les lectures hors du périmètre autorisé et les erreurs SQL inhabituelles autour d’une recherche ou d’un export.
Éléments à croiser
Suivre un même identifiant de requête du frontal au service. Rapprocher ensuite la session PostgreSQL si ce lien a été instrumenté ; une simple proximité horaire entre deux requêtes concurrentes ne suffit pas.
Limites de l’interprétation
Sans audit des objets retournés, on peut établir une requête suspecte sans connaître exactement les données exposées. Ne pas activer une journalisation indiscriminée des paramètres sur une base de production.
Comment réagir
Corriger les requêtes vulnérables et vérifier les autres fonctions qui utilisent la même construction. Conserver la version exposée et les journaux pour retrouver les lectures ou écritures possibles. Renouveler les secrets accessibles après avoir fermé la faille. Si des données ont été modifiées, comparer avec les sauvegardes et les journaux transactionnels avant restauration.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Une recherche ne doit jamais renvoyer les factures d’un autre client, même avec une valeur inattendue.
- Les tris, exports et tâches différées doivent appliquer la même séparation entre instructions SQL et données.
- Le compte utilisé par l’application doit avoir uniquement les droits nécessaires sur la base.
À vous de raisonner
La recherche utilise désormais des paramètres SQL. Quel contrôle faut-il encore tester avec deux comptes de clients différents ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Vérifiez que chaque compte ne reçoit que les factures auxquelles il a droit. Les paramètres empêchent une valeur de modifier la structure SQL ; ils ne remplacent pas l’autorisation sur les données. Testez aussi les exports et tris, et vérifiez les données renvoyées plutôt que le seul statut HTTP.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
returned_tenants- Champ pédagogique : liste des clients auxquels appartiennent les objets renvoyés. PostgreSQL et nginx ne produisent pas spontanément cette liste.
db_called=false- Dans le cas, le service a refusé la requête avant l’appel à la base ; cela exige une trace applicative de cette décision.
Corrélation requête → base → réponse
JournalTraces synthétiques normalisées ; les champs db_rows et tenant sont ajoutés ici par l’instrumentation de l’application.
10:02:11.040Z edge req=r41 actor=u17 tenant=A route=/factures status=200
10:02:11.045Z app req=r41 db_role=web_read query=invoice_search db_rows=2
10:02:11.047Z app req=r41 returned_tenants=A,B response_bytes=4210
10:03:08.002Z edge req=r42 actor=u17 tenant=A route=/factures status=403
10:03:08.004Z app req=r42 reason=invalid_sort_field db_called=falsePréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
nginx — journal d’accès HTTP
- Où les trouver
- Sur le frontal, dans le fichier désigné par access_log ; son contenu dépend de log_format. L’hébergeur peut devoir fournir cet export.
- Quoi relever
- Relever l’heure, la route, la méthode, le statut et l’identifiant de requête s’il est configuré. Un HTTP 200 décrit une réponse, pas les lignes consultées en base.
- Accès et prérequis
- Lecture des journaux serveur. Vérifier que la route est journalisée : les temps de réponse et identifiants de requête ne figurent pas forcément dans le format configuré.
PostgreSQL — journaux du serveur de base de données
- Où les trouver
- Sur le serveur PostgreSQL ou dans la console du service géré. Avec le collecteur actif, current_logfiles indique les fichiers en cours ; log_destination et log_directory déterminent la destination.
- Quoi relever
- Chercher l’instruction ou l’erreur SQL au même instant, avec le rôle et la session de base. Une erreur de syntaxe peut signaler une tentative ; une requête réussie peut n’en produire aucune.
- Accès et prérequis
- Accès administrateur ou export par l’exploitant. log_statement détermine les instructions enregistrées : le journal d’erreurs seul n’est pas un historique complet des requêtes. Attention aux paramètres confidentiels.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Pour établir une fuite entre clients, il faut lier la requête HTTP à l’identité, au client autorisé et aux objets réellement retournés. Cette décision d’accès relève de l’application, pas du journal nginx.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- GroupeCL0P
MOVEit : une injection SQL au service du vol de fichiers
À partir de mai 2023, une faille de MOVEit Transfer permet d’accéder à des données via une injection SQL. Les attaquants déploient un composant clandestin et volent des fichiers : cette campagne illustre l’extorsion par la fuite de données, sans supposer leur chiffrement.
Ce qu’établit la source. Campagne attribuée à CL0P par le FBI et la CISA dans leur avis conjoint du 7 juin 2023.
Consulter le rapport CL0P Ransomware Gang Exploits MOVEit Vulnerability (PDF) · PDF sur ECRAN22 pages · anglais · édition : 16 juin 2023 · Provenance et copieFBI / CISA · Mis à jour le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
Si vous utilisez le service
Vous n’avez pas à réparer la base de données du site. Si une recherche montre des documents d’autrui, arrêtez la consultation et signalez au service la page et l’heure.
Pour l’équipe qui exploite le service
- Signalez le problème au responsable du service sans explorer les données d’autrui.
- Faites corriger les chemins de requête concernés.
- Recherchez les lectures et modifications possibles pendant la période vulnérable.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- OWASP — SQL Injection Prevention — cheatsheetseries.owasp.org
- Python — sqlite3, paramètres SQL — docs.python.org
