Joyeux anniversaire, l'injection SQL, le bogue qui ne peut pas être corrigé

Une version de cet article a été initialement publiée dans Help Net Security. Il a été mis à jour et diffusé ici.

‍

Si vous occupez un poste pratique dans le domaine de la cybersécurité, qui nécessite une certaine familiarité avec le code, il y a de fortes chances que vous ayez dû penser à l'injection SQL... encore et encore. Il s'agit d'une vulnérabilité courante qui, bien que nous connaissions sa solution assez simple quelques semaines après sa première découverte, continue de sévir dans notre logiciel et offre une petite fenêtre d'opportunité aux attaquants potentiels si elle n'est pas détectée avant le déploiement.

Le 13 décembre 2020 a marqué le 22e anniversaire de SQL Injection, et bien que cette vulnérabilité soit assez ancienne pour être consommée, nous la laissons prendre le dessus sur nous au lieu de l'éliminer définitivement. En août de cette année, Freepik Company a révélé qu'elle avait a été victime d'une erreur d'injection SQL qui a compromis les comptes de 8,3 millions d'utilisateurs. Alors qu'un certain nombre d'entre eux utilisaient des identifiants tiers (par exemple Google, Facebook), quelques millions avaient des mots de passe non chiffrés exposés en même temps que leur nom d'utilisateur. Malheureusement pour eux et pour bien d'autres personnes en cours de route, les conséquences 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 » cette étape importante avec ce qui est considéré comme un problème d'héritage, analysons-le un instant. Pourquoi apparaît-il sans cesse, pourquoi est-il toujours si dangereux qu'il n'a pas quitté la première place du Top 10 de l'OWASP depuis des années, et pourquoi sa solution relativement simple ne figure-t-elle pas parmi les normes de référence générales en matière de développement de logiciels ?

Pourquoi l'injection SQL est-elle toujours d'actualité en 2021 ?

Un rapide coup d'œil sur une récente violation très médiatisée, cyberattaque dévastatrice contre FireEye, révèle un niveau de sophistication impressionnant : il s'agissait d'une attaque d'un État-nation hautement coordonnée utilisant un large éventail de techniques avancées qui semblaient avoir été personnalisées pour un cambriolage FireEye. Dans un communiqué, le PDG de FireEye, Kevin Mandia, a déclaré :

»Les attaquants ont adapté leurs capacités de pointe spécifiquement pour cibler et attaque FireEye. Ils sont hautement qualifiés en matière de sécurité opérationnelle et exécutés avec discipline et concentration... Ils ont utilisé une combinaison inédite de techniques dont nous ou nos partenaires n'avions jamais été témoins dans le passé.»

C'est un carburant cauchemardesque pour tout CISO, et si quelque chose comme cela peut arriver à FireEye, cela met en perspective la vulnérabilité réelle de nombreuses entreprises.

... sauf que c'est même pire des nouvelles pour l'organisation moyenne. FireEye est l'une des sociétés de cybersécurité les plus renommées au monde, et l'attaque réussie dont elle a été victime a nécessité des escrocs de haut niveau qui ont jeté tout ce qu'ils possédaient dans le cadre d'une exécution coordonnée et à grande échelle. Pour de nombreuses entreprises, une violation de données lucrative peut être possible en exploitant un simple bogue, assez rapidement, sans avoir besoin d'aucun cerveau. Et l'injection SQL est un exemple courant de cette dernière solution, encore utilisée par les amateurs de scripts qui cherchent à gagner rapidement de l'argent sur le Dark Web.

En mai 2020, un homme a été accusé de trafic de cartes de crédit et de piratage informatique, lorsqu'il a été découvert avec un support numérique contenant des centaines de milliers de numéros de cartes de crédit actifs. Il les a toutes récoltées à l'aide de techniques d'injection SQL, dans le cadre d'une opération qui a compromis de nombreuses entreprises et des millions de leurs clients.

En tant qu'industrie, nous sont s'améliorant sans cesse, mais l'injection SQL constitue toujours une menace importante et touche bien plus que les systèmes existants ou non patchés.

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

Nous n'arrêtons pas de dire que l'injection SQL est simple à corriger et que le code doit être écrit de manière à ne pas l'introduire du tout. Comme la plupart des choses, ce n'est facile que lorsqu'on vous a appris à bien faire les choses.

C'est là que la roue commence à vaciller dans le processus de développement logiciel. Les développeurs commettent les mêmes erreurs, ce qui entraîne des vulnérabilités récurrentes, telles que l'injection SQL infiltrant une base de code. Cependant, cela ne devrait pas être une surprise. La plupart des ingénieurs obtiennent leur diplôme sans avoir beaucoup appris sur le codage sécurisé, voire pas du tout. La plupart des formations en cours d'emploi sont inadéquates, en particulier 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 une raison de se préoccuper de la sécurité, ni une plateforme solide pour commencer à prendre davantage conscience de la sécurité. Des modèles de codage médiocres perpétuent des bogues tels que 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 sécurisé et de qualité plus élevé. L'écriture de modèles de codage sécurisés peut prendre plus de temps, mais le temps que vous y passez permet de gagner en efficacité, ce qui est inestimable plus tard dans le processus.

Y aura-t-il un jour des funérailles par injection SQL ?

Une métaphore funèbre est un peu morbide, mais en réalité, nos données sensibles seraient plus en sécurité si l'injection SQL était définitivement arrêtée. Je suis convaincu que nous célébrerons encore quelques anniversaires avant d'en arriver là, car la culture qui entoure la sécurité préventive et l'accent mis sur le codage sécurisé n'ont tout simplement pas suffisamment évolué pour que l'on puisse commencer à fermer le cercueil.

Des langages plus récents et plus robustes en termes de sécurité, tels que Rust, aident à éradiquer certains des bogues que nous avons traités pendant longtemps en utilisant des fonctions plus sûres, mais il existe une énorme quantité de logiciels existants, de systèmes anciens et de bibliothèques qui continueront à être utilisés et potentiellement vulnérables.

La responsabilité partagée en matière de sécurité dans le processus de développement (bonjour, DevSecOps) sera cruciale si nous voulons que les exploits « faciles » soient définitivement arrêtés. Les développeurs doivent être impliqués dès le début et soutenus pour qu'ils assument leur part de responsabilité dans la création d'un code plus sûr et de meilleure qualité.

Comment les développeurs doivent-ils aborder la correction d'un bogue d'injection SQL dans leur code ?

Nous avons mis en place un guide complet pour les développeurs qui souhaitent apprendre à identifier et à corriger l'injection SQL. Complétez le tout avec un défi ludique dans le langage de programmation de leur choix (même COBOL !) , cela fournit un excellent apprentissage de base qui aidera chaque développeur à créer un code plus sûr et de meilleure qualité.