L’analyse dynamique est une des meilleures pratiques de développement sécurisé. Parmi les nombreuses techniques d’analyse dynamique, le fuzzing jouit d’une grande popularité depuis son invention, et une multitude d’outils de fuzzing dont les degrés de sophistication varient ont été développés à ce jour.

Dans le contexte du fuzzing d’une application isolée, il peut s’avérer plutôt simple de rectifier les erreurs d’un système à mesure qu’elles sont repérées. Mais que se passe-t-il si un développeur est en charge d’un grand projet qui ne se prête pas facilement au fuzzing ? Dans ce cas, l’analyse dynamique doit être approchée d’une manière bien plus réfléchie.

Définir les objectifs

Définir les objectifs est une première étape cruciale. Le fuzzing peut être utilisé pour détecter des problèmes de sécurité, ou même tout type de problème lié à la correction. Un des nombreux avantages du fuzzing est qu’il permet de détecter de nombreux problèmes de gravité moindre qui n’auraient jamais été mis en évidence dans le cadre d’une utilisation normale. Ils peuvent s’avérer semblables en tous points à des failles de sécurité à la seule différence qu’aucune limite de confiance n’est réellement franchie.

Par exemple, si l’on procède au fuzzing d’un outil qui ne prévoit que des entrées en provenance du point de sortie d’un outil de confiance, ceci pourrait occasionner des plantages qui n’auraient jamais eu lieu lors d’une utilisation normale. Y a-t-il d’autres manières d’insérer des entrées corrompues dans cet outil ? Si la réponse est affirmative, alors nous sommes en présence d’une faille de sécurité. Si ce n’est pas le cas, il pourrait s’agir d’un problème de correction d’un « faible degré de priorité » n’ayant jamais été résolu. Cette situation peut être évitée en définissant clairement dans les objectifs l’importance de la résolution de l’ensemble des problèmes et non pas seulement de ceux qui ont trait à la sécurité. L’établissement d’exigences initiales dans le cadre de l’analyse dynamique peut permettre d’éviter de futures pertes de temps et frustrations.

Comprendre les limites de confiance

Une documentation et compréhension précise concernant l’emplacement où la vérification d’erreurs doit être effectuée est vitale pour garantir l’efficacité du processus. Les professionnels de la sécurité les plus expérimentés n’ont pas de problèmes à créer mentalement un modèle de haute sécurité où chaque fonction vérifie à titre défensif chacune des entrées. Cependant, le problème est bien plus complexe dans le monde réel. Ce type d’hypervigilance se révèle être une incroyable source de gaspillage et il ne survit jamais jusqu’à la phase de production.

En fournissant un effort supplémentaire afin d’établir un modèle mental juste des limites de sécurité du projet, l’équipe d’analyse comprendra mieux où les vérifications doivent être effectuées au niveau du flux de contrôle du programme et où elles doivent être omises, assurant ainsi une utilisation plus efficace du temps disponible.

Segmenter le projet selon l’interface

Les outils de fuzzing ont chacun leurs spécialités propres. Par conséquent, le projet doit être divisé en domaines attribués à ces différents types d’outils de fuzzing, selon leur interface – fichier, réseau, API.

Explorer les outils existants

De nouveaux outils de fuzzing sont en permanence en cours de développement, et les outils existants sont mis à jour afin d’intégrer de nouvelles fonctionnalités. En suivant l’évolution de ces développements, il est possible de dénicher de nouvelles améliorations en termes d’efficacité qui assureront un fonctionnement plus fluide du processus de fuzzing – même si cette aide ne concerne qu’un sous-ensemble du projet.

Composer des outils en interne

Il pourrait se produire une situation où les conditions amèneraient à réaliser une analyse dynamique sur un grand projet mêlant plusieurs langages et qui ne se prêterait à aucun outil existant. Dans ce cas, il pourrait se révéler intéressant de considérer la création d’un outil de fuzzing spécifique aux API du projet qui génère des entrées aléatoires selon ces API – en ajoutant de nombreuses assertions qui seront activées au moins une fois lors du fuzzing. La création d’un outil de fuzzing est relativement simple du moment que la nature de l’API ainsi que la manière dont celle-ci peut être introspectée sont claires – prenez un générateur de nombres aléatoires, établissez un conteneur ou une machine virtuelle isolée et lancez-vous.

Le fuzzing en vaut-il réellement la peine ?

Une critique commune concernant les outils de fuzzing est qu’après qu’ils aient fonctionné pendant un moment, ils ne trouvent plus de bugs. Mais le défaut évident de ce reproche est le suivant : ne pas trouver de bugs est précisément l’objectif à atteindre. Tout comme se débarrasser d’une suite de tests automatisés sous prétexte qu’elle trouve trop peu de régressions serait illogique, le même raisonnement s’applique au fuzzing. Si les outils de fuzzing ne trouvent plus de bugs, ceci doit être interprété comme une réussite – avant de poursuivre la recherche de menaces plus discrètes.

Quelle quantité de travail ?

La partie la plus exigeante du processus de fuzzing en termes de temps est le choix du meilleur outil pour le mettre en œuvre. Si un outil fonctionne dans le cadre du projet ou couvre même une partie du projet, alors le mettre en œuvre est un véritable jeu d’enfant. À mesure que l’outil révèle des problèmes du système, la décision de réparer ou non les bugs de faible priorité sera établie au cours du processus, ce qui donnera forme au développement des limites de confiance du projet. Il peut se présenter le cas d’un plantage pour lequel un correctif est généré et envoyé puis finalement refusé car l’entrée incorrecte générée par l’outil de fuzzing n’est à aucun moment en mesure d’atteindre cette partie du projet. Cette caractéristique pourrait bien rendre excessif le coût de la mise en place d’un contrôle supplémentaire.

Quelle que soit l’approche prise, assurez-vous que ses processus soient bien détaillés par écrit afin que les futurs développeurs puissent franchir ce stade sans difficultés.