Question de sécurité: comment sécuriser les collections Hibernate qui reviennent du client vers le serveur?

Question

J'ai simple POJO nommé "Parent", qui contient une collection d'objets "enfant".

il est tout simplement un à plusieurs association, les enfants ne connaissent pas leurs parents en veille prolongée / JPA,: ces objets enfants peuvent avoir différents types de parent donc il est plus facile de ne pas savoir le parent (pensez à l'enfant qui représente Tags et les parents peuvent être différents types d'objets qui ont des étiquettes).

Maintenant, j'envoyer mon objet parent à la vue du client de mon site Web pour permettre à l'utilisateur de le modifier.

Pour cela, j'utilise Hibernate / GWT / Gilead.

Mon mades utilisateur Quelques modifications et cliquez sur le bouton Enregistrer (ajax) qui envoie mon objet parent au serveur. champs de mes parents a été modifié, mais plus important encore, certains objets de l'enfant a été ajouté ou supprimé dans la collection.

Pour résumé, lorsque l'objet parent revient au serveur, il a maintenant dans sa collection: - de nouveaux objets « enfants » où id est nul et doit être persister - modification des objets « enfants » où id est non nul et doivent être fusionner - potentiellement piraté objets « enfants » où id est non nul, mais ne sont pas à l'origine détenue par la société mère - objets d'enfants disparus (supprimé): il faut supprimer

Comment vous enregistrez l'objet parent (et sa collection)? ne vous chargez la collection parent de base de données pour comparer chaque objet de la collection modifiée pour voir s'il n'y a pas d'objet piraté? Avez-vous videz l'ancienne collection (pour enlever orphelin) et re ajouter un nouvel enfant (mais il y a un enfant qui n'a pas été modifié)?

Merci

PS: désolé pour mon anglais, je l'espère vous comprendre le concept;)

Answer 1

La meilleure solution que j'ai trouvé est de gérer un DTO, créé manuellement. Le DTO envoie uniquement nécessaire données au client. Pour chaque champs que je veux mettre en mode lecture seule, je calcule une signature basée sur une clé secrète que j'envoie au client avec mon DTO.

Quand mon DTO revient au serveur, je vérifie la signature pour être sûr que mes inaltérables champs n'ont pas changé (recalcule la signature avec les champs à revenir et de le comparer à la signature revenir avec DTO)

Il me permet de spécifier lire uniquement les champs et assurez-vous que ne sont pas piraté mes objets.

Answer 2

Quelque chose dans votre pile doit fournir la logique dont vous parlez, et compte tenu de votre situation, il est probablement vous. Vous devrez obtenir l'état persisté actuel de l'objet en lisant votre source de données afin que vous puissiez faire la comparaison. Gardez à l'esprit que, si plusieurs actions légitimes peuvent mettre à jour votre objet parent et sa collection en même temps que vous devrez prendre grand soin sur la définition de votre grain de transaction et la nature thread-safe de votre code.

Ce n'est pas un problème simple par tout moyen et il pourrait bien être des caractéristiques cadres qui peuvent aider, mais je suis encore à trouver quelque chose qui a résolu ce pour toute mise en œuvre réelle du monde que je l'ai rencontré, en particulier où j'ai logique qui a essayé de faire la distinction entre les légitimes et les données « piraté ».

Vous pouvez envisager de modifier votre architecture telle que les parents et les enfants sont conservés dans des actions distinctes. Il peut ne pas être approprié dans votre cas, mais vous pourriez être en mesure d'avoir un grain plus fin de l'opération en découpant les actions de persistance et d'assurer la sécurité axée sur l'enfant qui rend votre problème de piratage un peu plus facile à gérer.

Bonne chance. Je vous recommande de dessiner un organigramme détaillé de votre logique avant de faire trop de codage.