Bonjour à tous.
J'ai souvent des difficultés lors du choix de la portée des variables, et surtout des méthodes/fonctions.
D'après ce que je sais :
- private : la ressource est accessible seulement par les Eléments de la class dans laquelle elle est défini (et les class internes je crois),
- protected : elle accessible au niveau du du package
- public : elle est disponible et accessible depuis n'importe où (dans le système local ou par une application installée sur une distante ?)
Corrigez-moi, s'il y'a des erreurs.
J'ai en faite 2 questions dans ce contexte : La première est d'ordre générale, et la deuxième concerne un cas précis.
- Question 1 :
Je n'ai toujours pas compris la raison "réelle", "concèrete", "pratique", en production pour laquelle on doit utiliser une portée adéquate .
Clairement, je dirai : que risque-ton en "pratique", pas en "théorie", si on déclarait une variable comme public alors qu'elle devrait être private ?
Exemple :
une class utilisateurs, permetant l'enregistrmeent d'un nouveal utilisateur.
Elle contient les variables :
- nom, prenom, dateNaissance, pseudo et motDePasse.
La logique de sécurité java, est que toutes ces variables devraient être private, et il devrai y avoir au mininum une methode setter pour chacune d'elle, et peut-être un setteur (si on veut lire les infos de la personne, avec la même class).
les setter/getter seront surement en protected, sinon public.
Mais question est :
où est le danger, le "risque de sécurité" si on ne définit pas de setter/getter et que l'on déclarait nos variable en protected, voir même en public ?
D'après les arguments que j'ai souvent lu sur les forum, les cours ... :
Argument 1 :
Supposant que l'utilisateur user1 saisi ses données : "nom u1", "prenom u2", "01/01/1990", "user1", "123456...."
sachant que les variables contenant ces données ne sont pas private, un autre utilisateur (user2) malintentionné pourrai modifier les donnée du user1,par exemple son pseudo, son mot de passe, ... puisqu'il suffirait que cet user2 de modifier la valeur des variables.
Je ne comprends pas cet argument et je la trouve irréalisable puisque :
quand user1 (ou user2 se connecte) à notre application (installé sur notre serveur) depuis son navigateur web ou autre client (installé loin de notre serveur),
arrivé sur la page d'inscription, une instance (un objet) de la classe personne sera crée et stocké en mémoire RAM.
Ni user1, ni user2 ne connaissent l'adresse mémoire que le système d'exploitation de notre serveur va allouer à chacune de nos variables d'objet (associé à chaque utilisateur) !
Partant de là, alors je ne comprends pas comment user2 pourrait t-il avoir accès au contenu des variables d'objet instancié par notre serveur, pour user1, puisque tout est en mémoire RAM, côté serveur !)
Remarque : je ne demande pas la technique qu'il pourrai utiliser, mais je veux juste montrer que ça me parait irréalisable, d'où le but de la question 1 ( que risque t-on "concrètement" si on déclare une variable public aulieu de private ?).
De plus quand on dit que déclarer une variable en public, permettrait à n'importe qui de le modifier directement.
Oui mais, une variable private avec un setter, revient au même non ?
Donc si on évite que user2 modifie les infos de user1, en y accédant directement en faisant personne1.passWord="xxxxxx", qu'est ce qui l’empêcherai de faire : personne1.setPassWord("xxxxxx")
... Et même si je prenais le cas où user2 est remplacé par une application malveillante, disant un virus, malware, etc. et que cette application malveillance se trouve déjà sur notre serveur.
... Supposons que notre application java est déployée dans /home/compte1/apps/AppEnLigne/package1/ (inscriptionUtilisateur.class, autreClass.class, ...)
et que :
- cas 1/ le virus se trouve dans le dossier ... /package1/ (donc au même endroit que les fichiers de class inscriptionUtilisateur et autres),
- cas 2/ le virus se trouve à l’extérieur du dossier ... /package1/
Dans les deux cas, le virus est lancé avec les droits d'exécution de nos fichiers de class contenu dans ..../package1/.
Donc il peut par exemple lancer la commande :
java ..../package1/inscriptionUtilisateur.class, sans probleme.
Même dans ces 2 cas, je pense qu'en lançant la class d'inscription, tout ce qu'il pourra faire, c'est ajouter des comptes inutile.
Et les objets de la class inscritionUtulisateur.class qui seront instanciés (à la la demande du virus) seront tout à fait séparés, différents de celui instancié à la demande de user1 (même-ci les demandes du virus et de user1 se font simultanément).
Là aussi, je ne voit pas non plus où est le risque d'insécurité "concrète" qui justifierai l'utilisation d'une portée private ou protected et non public ?
3eme cas de figure,
supposons que ce virus peut lire le contenu de la mémoire RAM (pour x raisons, faille de sécurité sur le serveur, etc),
Même dans ce cas, sincèrement, je ne vois toujours pas comment il pourrait trouver les adresses mémoires des ressources (variables) liées à la session de user1 ou autre user d'ailleurs , vu l'immensité de la mémoire RAM, la complexité des algorithme d’allocation (aléatoire) des adresses mémoire, etc !
Et, même-ci malgré l'aspect aléatoire d'allocation d'adresse mémoire, le virus finissait par les trouver et à modifier leur contenu, cela ne relèverait pas (à moins que je me trompe) de la responsabilité (faiblesse) du code java (notamment au niveau de la portée) mais je pense que cela devrait être imputé au système d'exploitation et/ou faille au niveau d'un autre éléments du système.
----- 2eme Argument évoquée dans le forum, pour justifier l'utilisation d'une portée adéquate. ----
Je me souviens avoir lu que imposer l’utilisateur passer par les getters / setteur était nécessaire pour ses raisons (de sécurité, ou je dirai plutôt de conformité des données) :
- contrôle du formatage, la validité de données, avant affectation vers la variables responsable. exemple : une date, nu numéro de téléphone, un code postale, ... doivent respecter un certain nombres de contraintes.
Sur ce point de vu, je suis d'accord mais appeler cela "sécurité" des données me parait pas approprié car peu induire en erreur (confusion).
Je pense que c'est plutôt de la "sûreté" (fiabilité, intégrité ou qualité) des données, mais pas sécurité". Encore une fois, merci de me corriger si je me trompe, car je ne suis que vieux débutant.
----- Fin du premier problème : question d'ordre générale sur la portée des variables / méthodes ------
Pour le deuxième problème, plus concret, je prefère créer un nouveau sujet, tout mélanger.
Merci de m'avoir lu et pour vos reponses.
A bientôt
Partager