Applications, sites et API
Particuliers et entreprisesInjection SQL
SQL injection — SQLi
Un service confond une donnée reçue avec une instruction pour sa base de données.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 les instructions qu’une application envoie à sa base de données. Le défaut vient de la façon dont elle construit sa requête : elle traite une donnée fournie par l’attaquant comme une instruction. Le problème ne se résume donc pas à la présence d’un caractère particulier. Selon le cas, l’attaquant peut lire, modifier ou supprimer des informations. La correction revient au développeur et à l’exploitant du service ; un simple visiteur ne peut pas la faire.
- 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
Si vous développez le service, transmettez les valeurs par les paramètres du pilote SQL et vérifiez les droits de chaque utilisateur. Limitez également les droits du compte de base de données utilisé par 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez 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. Le service doit chercher la cause. Voir une donnée d’autrui révèle un problème, mais ne permet pas de distinguer une injection SQL d’un autre défaut d’accès.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Une recherche de factures renvoie les données d’un autre client
Dans ce cas, le client A lance une recherche et reçoit aussi une facture du client B. La séparation entre leurs données a été contournée. L’application a inséré directement une valeur du navigateur dans sa requête SQL, et la base l’a interprétée comme une instruction.
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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- GroupeCL0P
MOVEit : une injection SQL au service du vol de fichiers
À partir de mai 2023, les attaquants exploitent une injection SQL dans MOVEit Transfer pour accéder aux données. Ils installent un composant clandestin et volent des fichiers. L’extorsion repose ici sur la fuite des données ; elle ne suppose pas que les fichiers aient été chiffrés.
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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
