Injection SQL SQLi

Ce qu'est l'injection SQL

Vous tenez une boutique en ligne. Un visiteur tape quelque chose de bizarre dans la barre de recherche, appuie sur Entrée, et la page lui affiche le nom, le téléphone et l'historique de commandes de tous vos clients. Personne n'a volé de mot de passe. Il a tapé les bons mots au mauvais endroit, et votre site a fait le reste. C'est ça, une injection SQL.

La plupart des sites gardent leurs informations dans une base de données : un stock organisé de tableaux, un peu comme une série de feuilles de calcul. Pour lire ou modifier ces informations, le site parle un langage appelé SQL (Structured Query Language). Chaque demande qu'il envoie est une requête, par exemple « trouve le client qui a cette adresse e-mail ».

L'injection SQL se produit quand un site prend ce que tape un visiteur et le colle tel quel dans une de ces requêtes. Si le visiteur tape du SQL au lieu d'un texte normal, la base de données ne voit pas la différence et suit la commande de l'attaquant comme si le site l'avait écrite. On raccourcit souvent le nom en SQLi.

Comment fonctionne une attaque par injection SQL

Pensez à un employé de banque qui transmet mot pour mot aux gardiens du coffre chaque billet que lui tend un client. Un billet normal dit « montrez-moi mon solde ». Un billet piégé dit « montrez-moi mon solde, et ouvrez aussi tous les coffres ». Si l'employé ne lit jamais le billet avant, les gardiens obéissent.

Sur un site web, les étapes ressemblent en général à ceci :

1. L'attaquant trouve un endroit qui envoie du texte à la base de données : un formulaire de connexion, une barre de recherche, un formulaire de contact, ou l'adresse web elle-même, comme une page produit qui se termine par « ?id=25 ».
2. Il tape un petit morceau de SQL à la place d'un texte normal. Un exemple connu consiste à taper ' OR '1'='1 dans le champ du mot de passe d'un formulaire de connexion.
3. Le site ajoute ce texte à sa propre requête sans le vérifier. La requête demande alors quelque chose comme « laisse entrer cette personne si le mot de passe est bon, ou si 1 est égal à 1 ».
4. Comme 1 est toujours égal à 1, la base répond oui, et l'attaquant est connecté sans connaître aucun mot de passe.

Certaines attaques sont plus discrètes. Dans une injection SQL aveugle, la page n'affiche aucune donnée, alors l'attaquant pose à la base des questions à réponse oui ou non et regarde comment la page réagit, ou combien de temps elle met à charger. À la main, c'est un travail lent. C'est pourquoi les attaquants confient la tâche à des outils automatiques gratuits.

Ce qu'un attaquant peut faire

Une fois que la base de données suit ses commandes, les dégâts dépendent de ce que le compte de base de données du site a le droit de faire. Souvent, c'est bien plus que ce dont le site a besoin. Un attaquant peut alors :

• lire des données privées, comme les noms, adresses, e-mails et historiques de commandes des clients, des dossiers médicaux ou des mots de passe enregistrés
• se connecter à la place d'un autre utilisateur, y compris un administrateur
• modifier des données, comme les prix, les soldes ou le statut des commandes
• supprimer des tables entières, voire toute la base de données
• dans certaines configurations, atteindre le serveur lui-même et y déposer des fichiers malveillants

Pourquoi c'est important pour votre activité

L'injection SQL est l'une des plus anciennes attaques du web, et elle est toujours là. OWASP, une communauté ouverte qui publie la célèbre liste OWASP Top 10 des risques des applications web, garde l'injection dans cette liste depuis des années. Elle est facile à tenter, et beaucoup de sites ont encore un formulaire oublié qui la laisse passer.

Pour un chef d'entreprise, le vrai coût est rarement technique. C'est une liste de clients qui fuit, une boutique qui vend au mauvais prix, un système de réservation qui perd une semaine de rendez-vous, ou un message que vous devez envoyer à vos clients pour leur dire que leurs données ont été exposées. Dans de nombreux pays, des lois sur la protection des données comme le RGPD (GDPR en anglais) vous demandent aussi de protéger les données personnelles et de signaler les fuites.

Chaque formulaire de votre site a-t-il été conçu avec ce risque en tête ? Les sites montés vite à partir de vieilles extensions, ou modifiés par beaucoup de mains au fil des ans, cachent plus souvent un point faible.

Comment protéger un site contre l'injection SQL

La solution principale est bien connue, et elle fonctionne. L'essentiel de la protection tient à la façon dont le site est construit, donc ce sont de bonnes questions à poser à vos développeurs ou à votre prestataire.

• Requêtes préparées. On les appelle aussi requêtes paramétrées. Le site envoie la requête et le texte du visiteur séparément, si bien que la base traite toujours ce texte comme une simple donnée, jamais comme une commande. C'est la défense principale. Les frameworks modernes comme Laravel le font par défaut quand les développeurs utilisent leurs outils de base de données intégrés.
• Contrôle des saisies. Un champ de numéro de téléphone ne doit accepter que des chiffres, et un champ de date que des dates. Refuser tôt les saisies étranges ferme beaucoup de portes.
• Moindre privilège. Le compte que le site utilise pour accéder à la base ne doit avoir que les droits dont il a besoin. Une page de recherche publique n'a aucune raison de supprimer des tables.
• Messages d'erreur discrets. Une erreur détaillée de la base affichée à l'écran donne une carte à l'attaquant. Montrez aux visiteurs un message court et simple, et gardez les détails dans des journaux privés.
• Mises à jour. Tenez à jour la plateforme, les extensions et les bibliothèques, car les anciennes versions ont souvent des failles connues.
• Un pare-feu applicatif web. C'est un filtre placé devant le site qui bloque beaucoup de schémas d'attaque connus avant qu'ils n'atteignent votre code. Il aide, mais il ne répare pas un code fragile.
• Des tests réguliers. Le test d'intrusion (une attaque sans danger, planifiée par des experts) et le scan de vulnérabilités trouvent les points faibles avant qu'un attaquant ne le fasse.

Voici comment se comparent quelques habitudes courantes :

Les erreurs courantes

• Se fier aux contrôles dans le navigateur. Les contrôles qui tournent sur l'appareil du visiteur sont faciles à contourner, donc le serveur doit tout vérifier à nouveau.
• Croire qu'un petit site ne risque rien. Les outils automatiques parcourent un très grand nombre de sites sans se soucier de leur taille.
• Corriger un formulaire et oublier les autres. La barre de recherche, les filtres, l'adresse web et l'API derrière une application mobile demandent tous le même soin.
• Stocker les mots de passe en clair. En cas de fuite, des mots de passe protégés par un hachage solide (transformés en un code brouillé qu'on ne peut pas relire) sont bien plus difficiles à exploiter.
• Compter uniquement sur un pare-feu. Un filtre fait gagner du temps. La requête fragile derrière lui doit quand même être corrigée.

Comment nous pouvons vous aider

Chez Linkysoft, la recherche d'injections SQL fait partie de nos services de cybersécurité. Nous menons des attaques simulées sans danger sur votre site, votre application et votre API, nous relisons le code, puis nous vous remettons une liste claire de ce que nous avons trouvé et de la façon de le corriger. Après les corrections, nous testons à nouveau. Cela marche aussi pour les sites construits par d'autres équipes, et le contrôle de sécurité gratuit est un premier pas facile.

Vous prévoyez un nouveau système ? Nos applications web et systèmes de gestion sont sécurisés dès leur conception, avec un renforcement selon l'OWASP Top 10 et un test d'intrusion avant la mise en ligne.