Joyeux anniversaire injection SQL, le bug impossible à éradiquer

Une version de cet article est initialement parue dans Help Net Security. Il a été mis à jour et syndiqué ici.

‍

Si vous occupez un poste opérationnel en cybersécurité — un rôle qui exige une certaine familiarité avec le code — il est fort probable que vous ayez dû vous pencher sur l'injection SQL... encore et encore. C'est une vulnérabilité courante qui, bien que son remède soit connu depuis les premières semaines suivant sa découverte, continue de gangrener nos logiciels et d'offrir une fenêtre d'opportunité aux attaquants potentiels si elle n'est pas détectée avant le déploiement.

Le 13 décembre 2020 marquait le 22e anniversaire de l'injection SQL. Bien que cette vulnérabilité soit assez vieille pour boire, nous la laissons prendre le dessus au lieu de l'éliminer une fois pour toutes. En août dernier, Freepik Company a révélé avoir été victime d'une erreur d'injection SQL qui a compromis les comptes de 8,3 millions d'utilisateurs. Bien qu'un certain nombre d'entre eux aient utilisé des connexions tierces (ex. Google, Facebook), quelques millions de mots de passe non chiffrés ont été exposés avec leurs noms d'utilisateur. Malheureusement pour eux et pour beaucoup d'autres, les retombées de ces incidents sont un véritable casse-tête, et rétablir la confiance avec la base d'utilisateurs est un processus de longue haleine.

Alors que nous « célébrons » cet anniversaire avec ce qui est considéré comme un problème hérité du passé, analysons-le un instant. Pourquoi continue-t-il de faire surface, pourquoi est-il toujours si dangereux qu'il occupe le haut du classement OWASP Top 10 depuis des années, et pourquoi son correctif relativement simple ne fait-il pas partie des normes de référence générales pour le développement logiciel ?

Pourquoi l'injection SQL est-elle toujours pertinente en 2021 ?

Un rapide coup d'œil à une brèche récente très médiatisée, la cyberattaque dévastatrice contre FireEye, révèle un niveau de sophistication stupéfiant : il s'agissait d'une attaque hautement coordonnée, menée par un État-nation, utilisant un large éventail de techniques avancées qui semblaient personnalisées pour le casse de FireEye. Dans une déclaration, le PDG de FireEye, Kevin Mandia, a déclaré :

« Les attaquants ont adapté leurs capacités de classe mondiale spécifiquement pour cibler et attaquer FireEye. Ils sont hautement formés à la sécurité opérationnelle et ont agi avec discipline et détermination... ils ont utilisé une combinaison inédite de techniques que nous ou nos partenaires n'avions jamais observée auparavant. »

C'est un véritable cauchemar pour tout CISO, et si une telle chose peut arriver à FireEye, cela permet de relativiser la vulnérabilité réelle de nombreuses entreprises.

… sauf que c'est une pire nouvelle pour l'organisation moyenne. FireEye est l'une des entreprises de cybersécurité les plus renommées au monde, et l'attaque réussie contre eux a nécessité des criminels de haut vol déployant tous leurs moyens dans une exécution coordonnée à grande échelle. Pour beaucoup d'entreprises, une brèche de données lucrative peut être réalisée en exploitant un simple bug, assez rapidement, sans aucun génie du crime. Et l'injection SQL est un exemple courant de ce dernier cas, toujours exploité par des « script kiddies » cherchant à gagner de l'argent rapidement sur le Dark Web.

En mai 2020, un homme a été inculpé pour trafic de cartes bancaires et piratage, après avoir été trouvé en possession de supports numériques stockant des centaines de milliers de numéros de cartes bancaires actifs. Il les a tous récoltés en utilisant des techniques d'injection SQL, lors d'une opération qui a compromis de nombreuses entreprises et des millions de leurs clients.

En tant qu'industrie, nous progressons constamment, mais l'injection SQL reste une menace importante qui affecte bien plus que les systèmes obsolètes ou non corrigés.

Pourquoi les développeurs la maintiennent en vie (et pourquoi ce n'est pas de leur faute)

Nous répétons sans cesse que l'injection SQL est simple à corriger et que le code devrait être écrit de manière à ne pas l'introduire du tout. Comme pour la plupart des choses, c'est facile seulement quand on vous a appris à bien faire.

C'est là que le bât blesse dans le processus de développement logiciel. Les développeurs commettent les mêmes erreurs, ce qui conduit à des vulnérabilités récurrentes comme l'injection SQL qui s'infiltrent dans une base de code. Cependant, cela ne devrait pas être une surprise. La plupart des ingénieurs obtiennent leur diplôme sans avoir appris grand-chose sur le codage sécurisé, voire rien du tout. La plupart des formations en entreprise sont inadéquates, surtout dans un environnement où la sécurité n'est pas considérée comme une priorité commerciale dans leur rôle.

Nous ne donnons pas aux développeurs de raison de se soucier de la sécurité, ni une plateforme solide pour commencer à devenir plus conscients des enjeux de sécurité. Les mauvaises pratiques de codage maintiennent en vie des bugs comme l'injection SQL, et nous devons mettre davantage l'accent sur la sensibilisation des développeurs à la sécurité, tout en leur donnant le temps d'écrire un code de qualité, plus sûr. Les modèles de codage sécurisé peuvent prendre plus de temps à écrire, mais le temps investi crée des gains d'efficacité inestimables plus tard dans le processus.

Y aura-t-il un jour des funérailles pour l'injection SQL ?

La métaphore des funérailles est un peu morbide, mais en réalité, nos données sensibles seraient plus en sécurité si l'injection SQL était enterrée pour de bon. Je suis toutefois convaincu que nous fêterons encore quelques anniversaires avant d'en arriver là, car la culture autour de la sécurité préventive et l'accent mis sur le codage sécurisé n'ont tout simplement pas assez évolué pour commencer à clouer le cercueil.

Des langages plus récents et plus robustes sur le plan de la sécurité, comme Rust, contribuent à éradiquer certains bugs auxquels nous sommes confrontés depuis longtemps grâce à des fonctions plus sûres. Toutefois, il existe une quantité colossale de logiciels hérités, de systèmes anciens et de bibliothèques qui resteront en service et potentiellement vulnérables.

Le partage de la responsabilité en matière de sécurité tout au long du processus de développement (le fameux DevSecOps) sera crucial pour mettre fin définitivement aux exploits « faciles ». Les développeurs doivent être impliqués dès le début et soutenus pour assumer leur rôle dans la création d'un code plus sûr et de meilleure qualité.

Comment les développeurs doivent-ils s'y prendre pour corriger une faille par injection SQL dans leur code ?

Nous avons élaboré un guide complet destiné aux développeurs souhaitant apprendre à identifier et à corriger les injections SQL. Agrémenté d'un défi ludique dans le langage de programmation de leur choix (même le COBOL !), ce guide offre des bases solides qui aideront chaque développeur à produire un code plus sûr et de meilleure qualité.