SQL Injection : l'une des vulnérabilités les plus exploitées

Il faut très tôt être conscient que les applications utilisées par les entreprises au Sénégal ne font pas l'exception face à la vulnérabilité qui occupe la première place des TOP 10 des failles applicatives les plus courantes.

Les données hostiles d'un attaquant peuvent duper l'interpréteur afin de l'amener à exécuter des commandes fortuites ou accéder à des données non autorisées.

Que sont les failles d’Injection ?

Les failles d’Injection surviennent quand une application envoie des données non fiables à un interpréteur (ceci parle aux développeurs).

Cause

Elles sont très fréquentes, surtout dans un code ancien et c’est très souvent le cas des applications web développées et utilisées dans nos entreprises. La réutilisation de code ou le copié-collé fait aveuglément par les développeurs sont parmi les premières causes de ces vulnérabilités.

"Détectabilité"

On retrouve souvent les failles d’Injection en SQL, LDAP, XPath, ou NoSQL; commandes OS; parseurs XML; entêtes SMTP, arguments de programme, etc. Elles se détectent facilement via le code mais difficilement via le test. Scanners et Fuzzers peuvent aider les attaquants à trouver les failles d’Injection.

Exploitabilité

Il est facile à un attaquant d’utiliser des scripts qui exploitent la syntaxe d’un interpréteur cible. Presque toute source de données peut être un vecteur d’injection, y compris des sources internes.

•  Présentation d'une Attaque par Injection SQL

           

Impacts Technique et Métier

L’impact est jugé sévère. En effet, l’Injection peut résulter en une perte ou une corruption de données, une perte de droits, ou un refus d’accès. L’Injection peut parfois mener à une prise de contrôle totale du serveur.

Considérez la valeur métier de la donnée impactée et la plateforme exécutant l’interpréteur : il faut savoir que toute donnée pourrait être volée, modifiée ou supprimée en cas d’attaque réussie. L’impact pourrait donc être financier ou sur la réputation et l’image de votre établissement.

Êtes-vous vulnérables ?

Le meilleur moyen de savoir si une application est vulnérable à l’Injection est de vérifier que toute utilisation d’interpréteurs sépare explicitement les données non fiables de la commande ou de la requête. Pour les appels SQL, cela signifie utiliser des variables liées dans toutes les instructions préparées et procédures stockées, et éviter les requêtes dynamiques. 

Vérifier le code est un moyen rapide et adéquat pour s’assurer que l’application utilise sainement les interpréteurs. Les outils d’analyse de code peuvent aider à localiser l’usage des interpréteurs et tracer leur flux de données à travers l’application. Les Pentesters peuvent valider ces problèmes en concevant des exploits qui confirment la vulnérabilité.

Le scan dynamique peut donner un aperçu des failles d’Injection existantes. Les scanners ne savent pas toujours atteindre les interpréteurs, ni si une attaque a réussi. Une mauvaise gestion d’erreur aide à trouver les failles.

Comment s’en prémunir ?

Empêcher une Injection exige de séparer les données non fiables des commandes et requêtes.

• La meilleure option est d’utiliser une API saine évitant toute utilisation de l’interpréteur ou fournissant une interface paramétrable. Attention aux APIs telles que les procédures stockées qui, bien que paramétrables, peuvent envelopper une Injection.

• En l’absence d’API paramétrable, vous devriez soigneusement échapper les caractères spéciaux en utilisant la syntaxe d’échappement spécifique à l’interpréteur.

• La « whitelist » est recommandée pour valider les données entrantes, mais n’est pas une défense complète, plusieurs applications requérant des caractères spéciaux; le cas échéant, seules les approches 1. et 2. sécurisent.

Référence : OWASP

AKM