[Secure Coding JAVA] Déclaration et Initialisation (DCL)

 

Je suis heureux de commencer avec vous cette semaine avec cette suite d’articles sur le Secure Coding, et pour commencer, en JAVA.

Grosses semaines qui arrivent avec la finalisation de la dernière partie de la CEHv9 ( Partie 4 ) et une surprise : La CompTIA Security + (401) sur Alphorm.com :), je vais donc essayer de finaliser cette suite d’articles cette semaine.

Le premier point que l’on va pouvoir explorer ensemble est la déclaration et l’initialisation.

Si on se réfère au Java Language Specification (JLS), l’initialisation d’une classe consiste en l’exécution de ses initialisateurs et l’initialisation de ses  champs statiques ( Les variables Class ).

Par conséquent, la présence d’un champ statique déclenche l’initialisation d’une classe.

Cependant, l’initialisation d’un champ statique pourrait dépendre de l’initialisation d’une autre classe, créant éventuellement un cycle d’initialisation.

Les programmes en général devraient – et les programmes sensibles à la sécurité doivent – éliminer tous les cycles d’initialisation de classe…

Code non conforme : 

La classe Cycle déclare une variable de classe finale statique privée, qui est initialisée avec  une  instance de la classe Cycle.

Les initialisateurs  statiques sont obligatoirement  invoqués une fois avant la première exploitation d’un membre de classe statique ou la première invocation d’un constructeur. L’intention du programmeur est de calculer le solde du compte en soustrayant les frais de traitement du montant déposé.

Cependant, l’initialisation de la variable de classe c se produit avant l’initialisation d’exécution du champ de dépôt, car elle apparaît par lexique avant l’initialisation du champ de dépôt.

Par conséquent, la valeur de dépôt vue par le constructeur, lorsqu’elle est invoquée pendant l’initialisation statique de c, est la valeur initiale de dépôt (0) plutôt que la valeur aléatoire.

En conséquence, le solde est toujours calculé à -10.

Le résultat est donc le suivant :

Code conforme : 

Cette solution modifie l’ordre d’initialisation de la classe Cycle afin que les champs soient initialisés sans créer de cycles de dépendance.

Le résultat est donc le suivant :

 

Un autre point très important : Il ne faut jamais utiliser des identificateurs existant  au niveau des librairies JAVA ( Java Standard Library ) afin de pouvoir éviter toute ambiguïté lors de initialisation ou appel des méthodes cibles.

 

Le niveau de risque au niveau de ce genre d’erreur de coding est assez bas ( LOW à MEDIUM ).