Comment se produisent les injections SQL et les autres injections applicatives ?

Évolution historique de la couche Application

Au fil des décennies, les protocoles applicatifs ont énormément évolué :

Les protocoles en clair (FTP, Telnet, HTTP, SMTP non chiffré) ont dominé les premières années d’Internet, car la priorité était la simplicité et l’ouverture.

Les problématiques de sécurité ont poussé à l’intégration de couches de chiffrement ou à la création de versions sécurisées (FTPS, SSH, HTTPS, SMTPS, etc.).

Aujourd’hui, on tend vers un usage quasi systématique du TLS (chiffrement), des authentifications fortes (OAuth, SAML, Kerberos, certificats X.509), et d’un filtrage avancé des données (WAF, IPS).

Malgré ces progrès, de nombreuses failles persistent dans les applications elles-mêmes : injection SQL, mauvaise gestion de sessions, fuites de données, problèmes de configuration…

Injections (SQL, NoSQL, LDAP, OS Command)

L’injection se produit lorsqu’un attaquant insère des données malveillantes dans un paramètre pris en compte par l’application, lequel n’est pas correctement filtré ou échappé.

Injection SQL : L’attaquant manipule une requête SQL pour lire ou modifier la base de données à l’insu de l’application.

Ceci permet le vol d’informations (ex. mots de passe, cartes bancaires) ou même l’effacement de tables.

Injection NoSQL : Les bases NoSQL ne sont pas épargnées.

Des requêtes JSON/MongoDB, par exemple, peuvent être altérées si on n’échappe pas correctement les paramètres.

Injection LDAP : Permet de contourner l’authentification ou d’extraire des informations d’annuaire si l’application utilise LDAP en backend.

Command injection : Certaines applications exécutent des commandes du système d’exploitation (shell) en utilisant des paramètres fournis par l’utilisateur.

Sans vérification stricte, on peut injecter des commandes arbitraires.