Depuis quelques années, je recueille des statistiques à partir des résultats de mes recherches sur la sécurité informatique. J’ai décidé de les partager un peu. Vous trouverez ici un exemple de rapport de test de pénétration – rapport. Dans un grand nombre d’entrevues avec des testeurs de pénétration, j’entends la question : « La sécurité des applications Web s’est-elle améliorée au fil des ans? » À mon avis – oui, mais seulement là où cela est en quelque sorte imposé par la réglementation de base. Les tests de pénétration contribuent-ils à améliorer la sécurité? – certainement oui!
Quelles données sont mentionnées
Au cours des deux dernières années, j’ai réussi plus de 100 tests de pénétration, audits de sécurité, analyses et tests. Il s’agissait d’applications différentes pour différents clients. La grande majorité étaient des applications Web. Lorsque l’application a été testée pour la première fois, elle a presque toujours trouvé une erreur qui classait la menace comme critique ou élevée. Pour les non-initiés, l’utilisation de ce type de vulnérabilité conduit à la prise de contrôle total de l’application (souvent aussi le serveur) ou permet l’accès à des données sensibles.
Les statistiques selon la classification de vulnérabilité sont les suivantes:
Progressant depuis des années, la détection d’un si grand nombre d’erreurs de sécurité dans les applications indique, à mon avis, de consacrer trop peu de temps de sécurité aux premiers stades de la création de logiciels. Je parle ici de l’éducation des développeurs, de l’inclinaison vers la sécurité dans la construction de l’architecture logicielle et de la modélisation des menaces. Sans cela, les vulnérabilités continueront d’être prises dans la phase finale de la création de logiciels (donc le coût de réparation est élevé) ou pire, seulement dans les environnements de production par ces pirates moins éthiques ;).
Vulnérabilités les plus fréquemment trouvées en raison du type
Let’s let’s let’s let’s on next statistics. Cette fois, les types de vulnérabilité les plus fréquemment trouvés.
Avec différentes couleurs, j’ai essayé de marquer la classification typique du risque d’une vulnérabilité donnée (bien sûr, en simplifiant, dans la pratique, il dépend de nombreux facteurs). Ensuite, il ressemble à ceci: marron – critique, rouge – grand, orange – moyen, vert-bas.
Tout d’abord, vous pouvez noter ici que les XSS sont le type le plus trouvé de vulnérabilité des plus criblés. Ce qui est surprenant pour moi, c’est qu’elle est connue depuis une trentaine d’années. De plus, c’est peut-être la classe la plus reconnaissable d’erreurs de sécurité. Sa présence devrait donc déjà être rare.
Ensuite, ils se classent comme des vulnérabilités liées à l’autorisation, c’est-à-dire un processus correct pour vérifier que l’utilisateur a le droit d’effectuer une opération spécifique. Le problème est particulièrement évident dans les applications avec des API étendues.
Si vous regardez les statistiques pour les erreurs les plus courantes – la première est la divulgation d’informations qui ne devraient pas être accessibles au public. Notez que la première des phases de piratage de l’application est la reconnaissance. Toute information redondante qui peut sembler insignifiante pourrait finalement s’avérer cruciale pour mener une attaque efficace.
Ensuite, la liste contient des messages d’erreur non génériques. Comme auparavant, elles révèlent souvent trop de données sensibles, par exemple sur les technologies utilisées.
Troisième est le problème qui, je crois, va passer dans les années à venir dans les statistiques à la première place. Il s’agit d’une dette technologique et de l’utilisation connexe de composants dont les vulnérabilités sont connues. De mon point de vue, les applications d’aujourd’hui sont en quelque sorte composées de nombreux petits blocs et chaînes de dépendance. Cela fait qu’il apparaît presque tous les jours qu’un petit composant est déjà obsolète. L’épinglement de sa version implique souvent la refonte d’une partie de l’application (du moins ces informations que je reçois des développeurs 😉 ), et ce processus consomme malheureusement beaucoup de ressources.
OWASP Top 10 vs Top 12 Pentester
La liste des vulnérabilités les plus fréquemment détectées par moi avec la liste OWASP Top 10 est la suivante:
Difficile de cartographier mes « découvertes » 1 à 1 sur la liste OWASPa. Nous ne trouverons pas ici le reflet de « Broken Authentification ». Cela s’explique simplement par le fait que la brute de suivi des comptes est le plus souvent hors de portée de mes tests (et que d’autres erreurs relevant de ce point ne figurent pas dans ma liste supérieure). Chercher en vain une référence au XXE. D’après mes observations, les erreurs de cette classe se produisent de moins en moins souvent. Je pense que cela est lié au fait que les frameworks responsables du traitement XMLy par défaut ne permettent plus l’utilisation d’entités externes. Toutefois, ce tableau montre que la liste OWASP TOP 10 n’est pas seulement une théorie sèche et qu’elle se reflète dans la pratique. Il vaut donc la peine d’utiliser les connaissances fournies par l’Open Web Application Security Project.
