Exemple de résultat de trace

L'exemple de résultat de trace suivant montre le flux de données entachées à travers une section d'une application qui contient une vulnérabilité d'injection SQL.

Le code examiné dans cet exemple ne valide pas ou n'assainit pas les données provenant d'une source non fiable, laissant la porte ouverte aux attaquants pour cibler la base de données de l'application.

Dans cet exemple de trace, la méthode de servlet doPost appelle request.getParameter. Cette méthode lit les données non sécurisées (le nom d'utilisateur) du corps HTTP POST, mais elle ne vérifie pas la validité des données et ne les assainit pas. Ces données non vérifiées, entachées, sont ensuite transmises à la méthode changePassword. Cette méthode transmet enfin les données entachées à la méthode statement.execute, où la vulnérabilité peut être exploitée.

Cette trace contient les informations suivantes :
  • request.getParameter("username") est marqué comme source (). Sa valeur de retour est l'origine de données non sécurisées.
  • statement.execute( ) a son premier paramètre marqué comme un collecteur (), car les données entachées (qui contiennent des commandes SQL malveillantes) peuvent être transmises au paramètre sql sans être validées ou assainies.
  • string.Builder( ).append( ) est marqué comme un propagateur de tache (), car il agit comme un conduit pour transmettre les données entachées d'un point (le premier paramètre) vers un autre (la valeur de retour).
  • Le flux de données entachées est marqué en rouge. La tache commence à request.getParameter et transmet les données entachées à la variable username. Les données sont ensuite passées à travers les propagateurs de tache jusqu'à ce qu'elles soient ajoutées à une instruction SQL et exécutées par la méthode statement.execute.
  • Chaque nœud de la trace fournit le numéro de ligne dans le code auquel la trace se produit, ainsi que l'extrait de code d'intérêt. Par exemple, la source () se trouve à la ligne 90.
  • A gauche de la trace, des barres bleues indiquent les emplacements où un correctif peut être implémenté pour supprimer la vulnérabilité de sécurité. Dans cet exemple, la validation et/ou l'assainissement des données doivent être ajoutés près du collecteur où les données entachées sont ajoutées à l'instruction SQL. Une bien meilleure solution serait d'exécuter correctement cette requête SQL comme une instruction préparée.
  • Dans cet exemple, les barres bleu plus foncé sur la gauche mettent en évidence une méthode qui est commune à la trace de plusieurs problèmes. C'est ce qu'on appelle un groupe de correctifs, qui indique un emplacement dans le code qui, s'il est abordé, peut résoudre plus d'un problème. Par conséquent, les groupes de correctifs doivent d'abord être étudiés. Dans cet exemple de trace, l'emplacement auquel append ( ) est appelé doit être étudié pour ce problème particulier.
    Dans le rapport d'examen, les problèmes sont répertoriés par groupe de correctifs si possible. Dans chaque groupe de correctifs, les types de problèmes sont énumérés en premier, suivis des problèmes individuels pour chaque type et de la trace pour chaque problème. Il existe deux types de recommandations de correction :
    • Si le correctif concerne une méthode qui fait partie du code de l'application, corrigez l'implémentation du code.
    • Si le correctif concerne un emplacement qui appelle un code tiers, corrigez l'utilisation du code.