Injection SQL et injection de commandes

SQL Injection (SQLi) se produit lorsqu’un attaquant insère ou « injecte » du code SQL malveillant dans un champ de saisie qui est ensuite transmis à une requête de base de données. Comme l’application concatène directement les données fournies par l’utilisateur dans une instruction SQL, la base de données ne peut pas distinguer les données légitimes des Commands fournies par l’attaquant. SQLi figure régulièrement parmi les Vulnerabilities Web les plus dangereuses de l’OWASP Top 10.

Une requête de connexion Vulnerable peut ressembler à ceci : SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. Un attaquant qui fournit ' OR '1'='1 comme nom d’utilisateur transforme la requête : la clause WHERE devient toujours vraie et l’authentification est entièrement contournée. Il s’agit de l’Injection fondée sur une tautologie classique.

Les attaques par SQL Injection prennent plusieurs formes : SQLi In-band renvoie directement les résultats dans la réponse HTTP (fondée sur les erreurs ou sur une union). SQLi Blind déduit les données à partir de réponses booléennes vraies ou fausses, ou de délais délibérés (SLEEP(5)). SQLi Out-of-band utilise des canaux secondaires, comme les recherches DNS, pour exfiltrer des données lorsque les réponses ne sont pas visibles.

La principale défense contre SQL Injection est l’utilisation de requêtes paramétrées (également appelées instructions préparées). Dans une requête paramétrée, la structure SQL est d’abord compilée et les données fournies par l’utilisateur sont transmises comme paramètre distinct : elles ne peuvent jamais modifier la structure de la requête. Cette approche est indépendante du langage et bien plus fiable que la seule assainisation des données saisies.

Bien que les requêtes paramétrées constituent la défense principale, la validation des données saisies fournit une couche secondaire importante. La validation par liste d’autorisation n’accepte que les caractères attendus (par exemple, uniquement des caractères alphanumériques dans un champ de nom d’utilisateur) et rejette tout le reste. La validation par liste de refus bloque les caractères malveillants connus, mais les attaquants encodent ou masquent souvent leurs charges utiles pour contourner ces listes, ce qui rend les listes d’autorisation bien plus robustes.

L’injection de Commands (injection de Commands OS) se produit lorsqu’une application transmet des données saisies par l’utilisateur, non assainies, à un Shell système. Contrairement à SQL Injection, qui cible les bases de données, l’injection de Commands cible directement le système d’exploitation : elle permet aux attaquants d’exécuter des Commands arbitraires avec les Privileges du processus du serveur Web. Sa gravité est classée CRITICAL et elle conduit souvent à la compromission complète du système.

Une application Web qui envoie une requête ping vers une adresse IP fournie par l’utilisateur peut utiliser : ping -c 1 INPUT. Si un attaquant fournit 8.8.8.8; cat /etc/passwd, le Shell interprète ; comme un séparateur de Commands et exécute les deux Commands. Les opérateurs d’Injection courants comprennent ;, &&, ||, | et la substitution de Commands par backticks.

La défense la plus sûre contre l’injection de Commands consiste à éviter complètement d’appeler des Commands du système d’exploitation à partir de données saisies par l’utilisateur et à utiliser des fonctions de bibliothèque qui accomplissent le même objectif. Lorsque les appels au Shell sont inévitables, transmettez les arguments sous forme de liste (jamais sous forme de chaîne concaténée), désactivez l’interprétation du Shell, validez les données saisies à l’aide d’une liste d’autorisation stricte et exécutez les processus avec le compte d’utilisateur disposant du moins de Privileges possible.

Le Top 10 de l’OWASP classe l’injection (qui englobe les injections SQL, NoSQL, OS et LDAP) parmi les risques les plus critiques pour la sécurité des applications. L’OWASP recommande une approche de défense en profondeur : utiliser des API sûres qui évitent l’interpréteur, effectuer une validation positive des entrées côté serveur (liste d’autorisation), échapper les caractères spéciaux à l’aide de la syntaxe propre à cet interpréteur et utiliser des contrôles SQL comme LIMIT afin d’empêcher la divulgation massive de données.

Un pare-feu applicatif web (WAF) peut détecter et bloquer les charges utiles d’injection courantes en inspectant les requêtes HTTP à la recherche de motifs correspondant à des signatures. Toutefois, les WAF peuvent être contournés à l’aide de techniques d’encodage et ne remplacent pas un développement sécurisé. Une journalisation correcte de l’application — en enregistrant les paramètres de requête, les codes de réponse et les messages d’erreur — permet aux équipes de sécurité d’identifier les tentatives d’injection lors de l’analyse d’un incident.

Les attaques par injection ont provoqué certaines des plus grandes fuites de données de l’histoire. La fuite de données d’Equifax en 2017 a exposé 147 millions d’enregistrements à cause d’une faille dans une application web. Une injection SQL visant le réseau PlayStation de Sony a compromis 77 millions de comptes en 2011. Ces incidents montrent que les failles d’injection ont un impact considérable sur l’entreprise : vol de données, amendes réglementaires, atteinte à la réputation et responsabilité juridique peuvent tous découler d’une attaque par injection réussie.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : l’injection SQL exploite des entrées non nettoyées concaténées dans des requêtes de base de données, l’injection de commandes transmet des entrées malveillantes à l’interpréteur de commandes de l’OS au moyen d’opérateurs tels que ; et |, et les requêtes paramétrées ainsi que l’évitement de shell=True constituent les principales défenses. Nous allons maintenant étudier les attaques par script intersite (XSS) et CSRF.