Comment les références aux membres de la classe privée peuvent-elles être dangereuses?

Question

Je suis en train de lire le CERT Secure Coding Standard for Java. Je suis aux prises avec ce rule. La gravité de cette règle est élevée, ce qui signifie qu'une violation de cette règle peut entraîner une escalade de privilèges ou l'exécution de code.

Je ne comprends pas vraiment comment une violation de cette règle peut mener à de telles choses fatales. Quelqu'un peut-il donner l'exemple d'une attaque contre un code qui viole cette règle?

Answer 1

Vous pouvez avoir un invariant que vous définissez dans le constructeur de la classe, par ex. que date contient le temps de création de l'instance:

class Foo { 
    private final Date date; 

    Foo() { this.date = new Date(); } 

    Date getDate() { return date; } 
} 

Maintenant, si je l'appelle getDate().setTime(0), je peux faire l'exemple ressembler, il a été créé à 1970-1-1 00:00:00Z.

Si vous avez une logique basée sur la date de création d'un Foo, il peut être manipulé pour se comporter différemment de cette manière.

Answer 2

En Java, vous contournez le spécificateur private en ayant une fonction non private qui renvoie une référence au membre. C'est parce qu'il est possible de modifier l'objet auquel le membre fait référence par le biais de cette référence.

Vous pouvez aussi bien être honnête à propos des choses, et marquer le membre private avec le même spécificateur d'accès que la fonction.

Answer 3

Si vous exposez une référence à l'objet mutable privé (par exemple Date ou tout Collection modifiable) sur le getter, vous pouvez modifier l'état de votre objet de l'extérieur.

Imaginez que vous avez méthode List<String> getNames() dans votre classe:

public class MyClass { 
    // fields and constructors are omitted 
    List<String> getNames() { 
     // return any mutable List implementation; for instance, ArrayList 
    } 
} 

Vous pouvez appeler myClass.getNames().add("name"), et cela modifiera l'état de l'instance MyClass. Ainsi, la personne qui utilise votre classe peut modifier l'état interne de ses instances.

Voir aussi 2e édition "Effective Java" de J. Bloch, article 39 "Faire des copies défensives en cas de besoin", p. 184, vous pouvez trouver une très bonne explication sur ce tiopic là.