Les attaques par injection de code, le tristement célèbre roi des vulnérabilités, ont perdu la première place à cause du contrôle d’accès brisé en tant que pire des pires, et les développeurs doivent en tenir compte.

Dans ce monde de plus en plus chaotique, il y a toujours eu quelques constantes sur lesquelles les gens pouvaient compter de manière fiable : le soleil se lèvera le matin et se couchera de nouveau la nuit, Mario sera toujours plus frais que Sonic the Hedgehog, et les attaques par injection de code occuperont toujours la première place sur la liste Open Web Application Security Project (OWASP) du top dix les plus courants et les vulnérabilités dangereuses que les attaquants exploitent activement.

Eh bien, le soleil se lèvera demain, et Mario a toujours un « one-up » sur Sonic, mais les attaques par injection de code sont tombées de la première place de la tristement célèbre liste OWASP, actualisée en 2021. L’une des plus anciennes formes d’attaques, vulnérabilités d’injection de code existent depuis presque aussi longtemps que les réseaux informatiques. La vulnérabilité globale est responsable d’un large éventail d’attaques, allant des attaques traditionnelles injections SQL aux exploits lancés contre les bibliothèques de navigation Object Graph. Cela inclut même des agressions directes contre des serveurs utilisant Techniques d’injection de système d’exploitation. La polyvalence des vulnérabilités d’injection de code pour les attaquants – sans parler du nombre d’endroits qui pourraient potentiellement être attaqués – a maintenu l’injection de code à la première place pendant de nombreuses années.

Mais le roi de l’injection de code est tombé. Longue vie au roi.

Cela signifie-t-il que nous avons enfin résolu le problème de vulnérabilité d’injection ? Aucune chance. Il n’est pas tombé loin de sa position d’ennemi numéro un de la sécurité, seulement jusqu’au numéro trois sur la liste OWASP. Ce serait une erreur de sous-estimer les dangers persistants des attaques par injection de code, mais le fait qu’une autre catégorie de vulnérabilité ait pu la surpasser est important, car cela montre à quel point le nouveau top dog OWASP est répandu et pourquoi les développeurs doivent payer. attention à ce qu’il avance.

La chose la plus intéressante, cependant, est peut-être que le Top 10 OWASP 2021 reflète une refonte importante, avec de toutes nouvelles catégories faisant leurs débuts : Conception non sécurisée, Échecs d’intégrité des logiciels et des données, et une entrée basée sur les résultats de l’enquête de la communauté : Demande côté serveur. Falsification. Ceux-ci indiquent une focalisation croissante sur les vulnérabilités architecturales et vont au-delà des bogues de surface pour la référence en matière de sécurité logicielle.

Le contrôle d’accès brisé prend la couronne (et révèle une tendance)

Le contrôle d’accès brisé a grimpé de la cinquième place sur la liste des dix principales vulnérabilités de l’OWASP jusqu’à la position actuelle de numéro un. Comme avec l’injection de code et les nouvelles entrées comme la conception non sécurisée, la vulnérabilité d’accès cassé englobe un large éventail de défauts de codage, ce qui ajoute à sa popularité douteuse car ils permettent collectivement des dommages sur plusieurs fronts. La catégorie comprend toute instance où les politiques de contrôle d’accès peuvent être violées afin que les utilisateurs puissent agir en dehors de leurs autorisations prévues.

Certains exemples de contrôle d’accès brisé cités par l’OWASP pour élever la famille de vulnérabilités au premier rang incluent ceux qui permettent aux attaquants de modifier une URL, l’état interne de l’application ou une partie d’une page HTML. Ils peuvent également permettre aux utilisateurs de modifier leur clé d’accès principale afin qu’une application, un site ou une API pense qu’ils sont quelqu’un d’autre, comme un administrateur avec des privilèges plus élevés. Il inclut même des vulnérabilités pour lesquelles les attaquants ne sont pas empêchés de modifier les métadonnées, ce qui leur permet de modifier des éléments tels que des jetons Web JSON, des cookies ou des jetons de contrôle d’accès.

Une fois exploitée, cette famille de vulnérabilités peut être utilisée par des attaquants pour contourner un fichier ou un objet autorisations, leur permet de voler des données ou même d’effectuer des fonctions destructrices au niveau de l’administrateur comme la suppression de bases de données. Cela rend le contrôle d’accès brisé extrêmement dangereux en plus d’être de plus en plus courant.

Il est assez convaincant – mais pas surprenant – que les vulnérabilités d’authentification et de contrôle d’accès deviennent le terrain le plus fertile pour les attaquants à exploiter. le dernier de Verizon Rapport d’enquête sur les violations de données révèle que les problèmes de contrôle d’accès sont répandus dans presque tous les secteurs, en particulier l’informatique et les soins de santé, et 85 % de toutes les violations impliquaient un élément humain. Désormais, « l’élément humain » couvre les incidents tels que les attaques de phishing, qui ne sont pas un problème d’ingénierie, mais 3% des violations impliquaient des vulnérabilités exploitables et, selon le rapport, étaient principalement des vulnérabilités plus anciennes et des erreurs humaines, comme une mauvaise configuration de la sécurité.

Alors que ces bogues de sécurité décrépits comme XSS et l’injection SQL continuent de faire trébucher les développeurs, de plus en plus, il est devenu évident que la conception de la sécurité de base échoue, cédant la place à des vulnérabilités architecturales qui peuvent être très avantageuses pour un acteur de la menace, surtout si elles ne sont pas corrigées après la faille de sécurité dans une version particulière d’une application est rendue publique.

Le problème est que peu d’ingénieurs reçoivent une formation et un développement des compétences qui vont au-delà des bases, et encore moins voient vraiment leurs connaissances et leurs applications pratiques étendues au-delà des bogues localisés au niveau du code qui sont généralement introduits par les développeurs en premier lieu.

Prévenir les bugs que les robots trouvent rarement

La famille nouvellement regroupée de vulnérabilités de contrôle d’accès brisé est assez diversifiée. Vous pouvez trouver des exemples spécifiques de contrôles d’accès cassés et comment les arrêter sur notre chaîne YouTube et notre Blog. Ou mieux encore, essayez par vous-même.

Cependant, je pense qu’il est important de célébrer ce nouveau Top 10 OWASP ; en effet, il est plus varié, englobant un plus large éventail de vecteurs d’attaque qui incluent ceux que les scanners ne détecteront pas nécessairement. Pour chaque faiblesse détectée au niveau du code, des failles architecturales plus complexes passeront inaperçues pour la plupart des technologies de sécurité, quel que soit le nombre de boucliers et d’armes automatisés dans l’arsenal. Alors que la part du lion de la liste OWASP Top 10 est toujours compilée sur la base de données de numérisation, de nouvelles entrées couvrant les défaillances de conception non sécurisée et d’intégrité des données – entre autres – montrent que les horizons de formation des développeurs doivent s’étendre rapidement pour réaliser ce que les robots ne peuvent pas.

En termes simples, les scanners de sécurité ne font pas d’excellents modélisateurs de menaces, mais une équipe de développeurs compétents en sécurité peut aider l’équipe AppSec de manière incommensurable en augmentant leur QI de sécurité conformément aux meilleures pratiques, ainsi qu’aux besoins de l’entreprise. Cela doit être pris en compte dans un bon programme de sécurité, étant entendu que bien que le Top 10 de l’OWASP soit une excellente base de référence, le paysage des menaces est si rapide (sans parler des exigences des objectifs de développement internes) qu’il doit y avoir un plan pour aller plus loin et plus précisément avec la montée en compétence des développeurs en matière de sécurité. Ne pas le faire entraînera inévitablement des occasions manquées de remédier rapidement et entravera une approche holistique réussie de la cybersécurité préventive dirigée par l’homme.

A propos de l’auteur: Matias Madou est le co-fondateur et CTO de Secure Code Warrior. Il a plus d’une décennie d’expérience pratique en sécurité logicielle, titulaire d’un doctorat. en ingénierie informatique de l’Université de Gand.