Impact de l'injection SQL
L'injection SQL (SQLi) permet à un attaquant d'interférer avec les requêtes qu'une application effectue sur sa base de données [S1]. Le principal impact comprend l'accès non autorisé à des données sensibles telles que les mots de passe des utilisateurs, les détails de la carte de crédit et les informations personnelles [S1].
Au-delà du vol de données, les attaquants peuvent souvent modifier ou supprimer des enregistrements de base de données, entraînant des changements persistants dans le comportement des applications ou une perte de données [S1]. Dans les cas très graves, SQLi peut être escaladé pour compromettre l'infrastructure back-end, permettre des attaques par déni de service ou fournir une porte dérobée persistante dans les systèmes de l'organisation [S1][S2].
Cause première : gestion des entrées dangereuses
La cause première de l'injection SQL est la neutralisation incorrecte des éléments spéciaux utilisés dans une commande SQL [S2]. Cela se produit lorsqu'une application construit des requêtes SQL en concaténant des entrées influencées de l'extérieur directement dans la chaîne de requête [S1][S2].
Étant donné que l'entrée n'est pas correctement isolée de la structure de la requête, l'interpréteur de base de données peut exécuter des parties de l'entrée utilisateur sous forme de code SQL plutôt que de la traiter comme des données littérales [S2]. Cette vulnérabilité peut se manifester dans différentes parties d'une requête, notamment les instructions SELECT, les valeurs INSERT ou les instructions UPDATE [S1].
Correctifs concrets et atténuations
Utiliser des requêtes paramétrées
Le moyen le plus efficace d'empêcher l'injection SQL consiste à utiliser des requêtes paramétrées, également appelées instructions préparées [S1]. Au lieu de concaténer des chaînes, les développeurs doivent utiliser des mécanismes structurés qui imposent la séparation des données et du code [S2].
Principe du moindre privilège
Les applications doivent se connecter à la base de données en utilisant les privilèges les plus bas requis pour leurs tâches [S2]. Un compte d'application Web ne doit pas disposer de privilèges administratifs et doit être limité aux tables ou opérations spécifiques nécessaires à sa fonction [S2].
Validation et encodage des entrées
Bien qu'elle ne remplace pas le paramétrage, la validation des entrées fournit une défense en profondeur [S2]. Les applications doivent utiliser une stratégie d'acceptation connue, validant que l'entrée correspond aux types, longueurs et formats attendus [S2].
Comment FixVibe le teste
FixVibe couvre déjà l'injection SQL via le module de scanner fermé active.sqli. Les analyses actives ne s'exécutent qu'après vérification et attestation de la propriété du domaine. La vérification analyse les points de terminaison GET de même origine avec des paramètres de requête, établit une réponse de base, recherche les anomalies booléennes spécifiques à SQL et ne signale un résultat qu'après une confirmation de synchronisation sur plusieurs longueurs de délai. Les analyses de référentiel aident également à détecter la cause première plus tôt grâce à code.web-app-risk-checklist-backfill, qui signale les appels SQL bruts créés avec l'interpolation de modèle.