Sécurité et logiciel – Vérification (SDL phase 4)

Analyse dynamique

L’analyse dynamique permet d’analyser le comportement du logiciel durant son utilisation. Cette analyse porte sur les éléments suivants :

  • La détection de débordement mémoire
  • La détection de l’utilisation de pointeurs non alloués
  • La détection de fuite mémoire
  • La détection de l’utilisation de variables non initialisées
  • Déterminer le code effectivement chargé et utilisé par l’application (librairies dynamiques)
  • Analyser les flux de données entrants et sortants de l’application.

Pour les flux sortants (réseaux, fichiers…) de l’application, il convient de vérifier que l’application ne laisse pas sortir d’informations sensibles par erreur, par exemple en écrivant des mots de passe dans les traces générées.

Parmi les outils d’aide à l’analyse dynamique, on peut citer les outils gratuits suivants :

  • AppVerifier [APPVERIFIER], Dr. Memory [DR. MEMORY] et Valgrind [VALGRIND] pour les analyses au niveau de la mémoire.
  • Nmap [NMAP] permet d’identifier les ports de communication ouverts sur un système.
  • WireShark [WIRESHARK] pour l’analyse des flux réseaux.
  • La suite d’outils développée par Sysinternals [SYSINTERNALS] pour déterminer les librairies chargées par l’application, les ports et les fichiers ouverts par l’application.

Cette liste n’est pas exhaustive.

En plus des outils spécifiquement conçus pour l’analyse dynamique, certains compilateurs et certains linkers offrent également des fonctionnalités pour ce type d’analyse :

  • Détection de débordement mémoire
  • Détection de l’utilisation de pointeurs non alloués
  • Détection de fuite mémoire
  • Détection de l’utilisation de variables non initialisées

Tests par injection de fautes aléatoires (Fuzzing)

Le fuzzing consiste à injecter des données aléatoires de façon volontaire dans les entrées d’un logiciel pour vérifier que celui-ci traite correctement ces données, c’est-à-dire sans provoquer d’erreurs inattendues et en appliquant à ces données un traitement correct. Les données injectées peuvent être totalement aléatoires ou seulement mal formées.

Parmi les outils de tests par injection de fautes aléatoires gratuits, on peut citer wfuzz [WFUZZ].

Certains outils de fuzzing sont conçus pour tester un type particulier d’application (web, VOIP …).

Les tests par injection de fautes aléatoires sont généralement automatisés.

Tests d’injection de commandes, SQL, LDAP, XPATH, XSS

Les tests d’injection de commandes, SQL, LDAP, XPATH, XSS consistent à forger puis à injecter des données dans les entrées d’un logiciel pour faire exécuter par celui-ci une commande système, une requête SQL, LDAP, XPATH, XSS non prévue, dans le but de compromettre la sécurité du logiciel ou du système l’hébergeant. Le but de ces tests est de vérifier que les entrées traitent les données reçues avec toutes les précautions nécessaires, par exemple en échappant correctement les caractères spéciaux. Il faut tester un type d’injection seulement si la technique associée est utilisée par le logiciel.

Parmi les outils de tests d’injection gratuits, on peut citer :

  • Commix [COMMIX] pour les injections de commandes.
  • sqlmap [SQLMAP] pour les injections de requêtes SQL.

Cette liste n’est pas exhaustive.

Ces tests sont partialement automatisables.

Scanner de vulnérabilités

Les scanners de vulnérabilités permettent d’identifier les vulnérabilités effectives ou potentielles d’une application. Ils sont souvent utilisés en première analyse par les responsables de la sécurité de l’information et les auditeurs.

La pertinence des résultats fournis par ces scanners doit être évaluée en fonction de l’analyse de risques préalablement réalisée. Si une vulnérabilité identifiée par le scanner est considérée comme non pertinente, et n’est à ce titre pas protégée par une mesure de sécurité, il faut être en mesure de justifier cette décision auprès d’un auditeur ayant également détecté cette vulnérabilité.

Le test doit être effectué au plus près de l’application à tester. Il convient de désactiver les systèmes de sécurité mis en place sur le système hôte pour protéger le système et l’application. Dans le cas contraire le test portera sur ces systèmes de sécurité et non sur l’application elle-même.

Ces tests doivent être effectués dans un environnement de test. Le scanner ayant un comportement similaire à celui d’un attaquant potentiel, il convient de réaliser ce type de test en collaboration avec le service informatique.

Il existe un scanner de vulnérabilité gratuit. Il s’agit d’OpenVAS [OPENVAS]. L’outil Qualys [QUALYS] est disponible à partir de 1’000 Euro par année.

Revue de la surface d’attaque et de la modélisation des menaces

Durant le développement d’une application, il n’est pas rare que celle-ci s’éloigne des exigences définies durant les phases initiales du projet. Il est donc important de passer en revue la surface d’attaque et la modélisation des menaces afin de vérifier que l’application implémentée applique les mesures adéquates aux éventuels nouveaux vecteurs d’attaque résultant de ces modifications.