Le fuzzing côté client est une technique de test qui consiste à saisir des données aléatoires, mal formées ou inattendues dans des applications basées sur un navigateur afin d'identifier les failles de sécurité et les bogues. Il permet de détecter les problèmes liés au traitement des entrées, à la manipulation du DOM et à l'exécution de JavaScript. Les outils de fuzzing modernes combinent souvent la génération aléatoire d'entrées avec des algorithmes guidés par la couverture afin d'optimiser l'efficacité des tests.
Le fuzzing est une technique de test automatisée qui fournit à un programme de grands volumes d'entrées aléatoires, malformées ou délibérément inattendues pour voir ce qui casse. Appliqué au côté client, il cible le navigateur et les applications basées sur le navigateur : analyseurs HTML et CSS, moteur JavaScript, API DOM, décodeurs d'images et de polices, et code de traitement des entrées des applications web. Un fuzzer génère ou fait muter des cas de test, les exécute et guette les plantages, les blocages, les erreurs de mémoire ou les échecs d'assertion qui signalent un bogue. Les fuzzers modernes sont guidés par la couverture : ils instrumentent le code et privilégient les entrées qui atteignent de nouveaux chemins d'exécution, explorant progressivement une plus grande partie du programme qu'un test aléatoire à l'aveugle ne le ferait.
Le fuzzing est l'un des moyens les plus productifs de trouver des bogues sérieux avant les attaquants. Les éditeurs de navigateurs pratiquent un fuzzing continu à grande échelle pour découvrir les failles de corruption de mémoire dans les moteurs et les analyseurs, et ce sont les mêmes techniques que les attaquants et les chercheurs utilisent pour découvrir des zero-days exploitables. Pour les développeurs d'applications web, fuzzer les gestionnaires d'entrée et les analyseurs côté client fait apparaître des cas limites, comme des données malformées qui déclenchent un XSS basé sur le DOM ou des plantages, que les tests fondés sur des exemples manquent. Parce qu'il explore des entrées qu'un humain ne penserait jamais à écrire, le fuzzing trouve à plusieurs reprises des défauts dans du code mûr et bien examiné, ce qui explique pourquoi il fait partie intégrante du développement sécurisé et de la recherche de vulnérabilités.
Traitez le fuzzing comme une composante d'un cycle de développement sécurisé plutôt que comme une action ponctuelle. Choisissez des outils guidés par la couverture, donnez-leur un bon corpus d'entrées de départ et une cible qui échoue bruyamment (assertions plus des sanitizers comme ASan pour le code natif), et exécutez-les en continu afin que le nouveau code continue d'être sollicité. Combinez le fuzzing avec des sanitizers pour détecter les erreurs de mémoire silencieuses, et triez et corrigez chaque plantage reproductible, car un plantage marque souvent une condition exploitable. Pour les applications web, fuzzez tout code qui analyse des entrées non fiables et associez-le à l'analyse statique et à la revue de code. Le fuzzing complète, mais ne remplace pas, la surveillance de ce que le code tiers fait réellement en production.
Les deux utilisent la même technique. Les défenseurs fuzzent leur propre logiciel pour trouver et corriger les bogues avant la publication, tandis que les attaquants et les chercheurs fuzzent des logiciels largement utilisés pour découvrir des vulnérabilités qu'ils peuvent exploiter ou signaler. La méthode est neutre ; le résultat dépend de qui l'exécute et de ce qu'il fait des plantages qu'il découvre.
C'est un fuzzing qui instrumente la cible pour mesurer quels chemins de code chaque entrée atteint, puis priorise et fait muter les entrées qui débloquent de nouveaux chemins. Cette boucle de rétroaction explore une bien plus grande partie du programme que des entrées aléatoires seules, trouvant des bogues plus profonds plus vite. AFL et libFuzzer en sont des exemples bien connus.
We answer client-side security questions every day. Bring yours.