Le fuzzing (ou test à données aléatoires) est une technique pour tester des logiciels. L'idée est d'injecter des données aléatoires dans les entrées d'un programme. Si le programme échoue (par exemple en plantant ou en générant une erreur), alors il y a des défauts à corriger. Exemples de points d'entrée d'un programme :
Fichiers
Périphériques (clavier, souris, etc.)
Variables d'environnement
Réseau
Limitation des ressources (mémoire, disque dur, temps CPU, etc.)
etc.
Le grand avantage du fuzzing est que l'écriture de tests est extrêmement simple, ne demande aucune connaissance du fonctionnement du système et permet de trouver des vulnérabilités facilement. D'ailleurs, le fuzzing est également utilisé pour traquer des failles de sécurité ou dans la rétro-ingénierie.
La première trace du fuzzing est la publication datant du : « An Empirical Study of the Reliability of UNIX Utilities » écrite par Barton P. Miller, Lars Fredriksen, et Bryan So. Le résumé indique que durant les essais ils ont été capables de faire planter « entre 25 et 33 % des programmes utilitaires de n'importe quelle version d'UNIX ». Le rapport présente les outils de test mais également l'origine des erreurs.
Le fuzzing est tellement simple à utiliser et si efficace pour trouver des vulnérabilités que le chercheur en sécurité informatique Charlie Miller a refusé de dévoiler les vulnérabilités zero day trouvées dans le code de logiciels célèbres (contrairement au règlement du concours de sécurité informatique Pwn2Own), afin de protester contre les éditeurs qui n'utilisent pas assez cette technique simple selon lui.
Cette simplicité est toutefois à relativiser lorsqu'il s'agit de trouver des vulnérabilités dans l'implémentation de protocoles notoirement connus (HTTP par exemple) dans des serveurs. En effet, les paramètres d'entrée sont souvent testés et protégés rigoureusement (contrôle de forme), chaque erreur menant à un abandon immédiat de la routine de traitement de la requête test. La probabilité de trouver des vulnérabilités par fuzzing en un temps acceptable devient alors très faible.
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.
L'automatisation de test permet de jouer à volonté des tests de régression à la suite de la livraison d'une nouvelle version d'une application. L'automatisation d'un test n'a de sens que si le test répond à un certain nombre de critères : le test est systématique : il doit être exécuté à chaque nouvelle version de l'application. le test est répétitif : il est présent dans de nombreux scénarios de test. le test est automatisable : il est possible techniquement de faire jouer le test par un robot.
thumb|upright|Symbole utilisé pour communiquer au sujet de la vulnérabilité Heartbleed. Heartbleed est une vulnérabilité logicielle présente dans la bibliothèque de cryptographie open source OpenSSL à partir de , qui permet à un « attaquant » de lire la mémoire d'un serveur ou d'un client pour récupérer, par exemple, les clés privées utilisées lors d'une communication avec le protocole Transport Layer Security (TLS). Découverte en et rendue publique le , elle concerne de nombreux services Internet.
Les tests système de logiciel ou de matériel réfèrent à un processus de test d'un système intégré afin d'évaluer sa conformité aux exigences spécifiées. Les tests système appartiennent à la classe des tests de type boîte noire, et en tant que tels, ne devraient exiger aucune connaissance de la conception interne du code ou de la logique. En règle générale, les tests système prennent comme entrée tous les composants logiciels « intégrés » (ayant réussi les tests d'intégration) mais aussi le système logiciel lui-même intégré à n'importe quel système matériel compatible.
Memory corruption and type safety flaws dominate the threat landscape. We will approach current research
from three dimensions: sanitization (finding flaws through runtime monitors); fuzzing (testing
This course focuses on software security fundamentals, secure coding guidelines and principles, and advanced software security concepts. Students learn to assess and understand threats, learn how to d
Students will be exposed to modern software engineering research and will learn how to evaluate, synthesize, and apply these research findings to their own independent projects. Time will also be spen
Explore fuzzing comme une technique automatisée pour améliorer la couverture du programme dans les tests de sécurité.
Explore le flou, les oracles de bogues, les revues de codes et les techniques de test automatisé, soulignant l'importance de la désinfection pour détecter les défauts.
Explore les principes avancés de Chaos Engineering, la gestion des risques, l'automatisation et les tests d'injection de défauts.
The pursuit of software security and reliability hinges on the identification and elimination of software vulnerabilities, a challenge compounded by the vast and evolving complexity of modern systems. Fuzzing has emerged as an indispensable technique for b ...
EPFL2024
, , , , ,
Fuzzers effectively explore programs to discover bugs. Greybox fuzzers mutate seed inputs and observe their execution. Whenever a seed reaches new behavior (e.g., new code or higher execution frequency), it is stored for further mutation. Greybox fuzzers d ...
Berkeley2023
,
Fuzzing has emerged as the most broadly used testing technique to discover bugs. Effective fuzzers rely on coverage to prioritize inputs that exercise new program areas. Edge-based code coverage of the Program Under Test (PUT) is the most commonly used cov ...