J'avais juste cette pensée, je ne sais pas si je suis ralentissement.
Habituellement, je stocke l'identifiant de l'article que je modifie dans un champ caché. Ensuite, dans le backend (j'utilise PHP / Zend Framework BTW), je l'obtiens pour déterminer quel élément est édité. Mais alors je pensais, dans quelque chose de plus sûr, par exemple. Modifier le profil, l'utilisateur peut en quelque sorte modifier un champ caché non? Ensuite, il peut éditer le profil de quelqu'un d'autre. Je sais pour le profil d'édition, je peux obtenir le formulaire ID de la variable de session, mais si je reçois quelque chose qui me demande de stocker l'ID quelque part? P>
J'ai ACL (Zend_ACL) Je fais cela. Fondamentalement, saisissez l'ID des paramètres de la demande P>
$id = $req->getParam('id');
5 Réponses :
Stockage ID en valeur cachée n'est pas tout à fait sûr. Généralement, nous stockons ID dans la variable de session.
Il n'est pas nécessaire d'utiliser la variable de session. Il est plus sémantique (et plus facile) de vérifier que les données d'affichage de l'utilisateur ont la permission de modifier l'enregistrement qu'ils affichent des données.
ah. Meaugar, tu as formulé ce que je pensais très bien! avoir 2 variables qui soi-disant shld stocker la même valeur, est désordonnée et peut-être sujette aux erreurs
L'OP vous demande comment déterminer ce que l'enregistrement édité est sans qu'il soit modifié, c'est-à-dire comment ils stockent l'ID pour revenir sur le serveur pour interroger l'enregistrement avec une déclaration de PPShein. Vous stockeriez l'identifiant dans une session afin de ne pas pouvoir être modifié, puis vérifiez les autorisations pour cet enregistrement. Vous ne pouvez pas vérifier les autorisations si vous ne savez pas quel document est édité.
@webnoob, j'ouvre parfois plusieurs onglets de Stackoverflow avec plusieurs réponses / questions simultanées. Vous pouvez voir que, sans faire des boucles dans l'air, votre solution ne permet qu'une seule fenêtre ouverte / onglet d'un produit édité. Pas très convivial.
@Italy moav bon point. Sur cette note, seule la seule façon vraie de manipuler qu'il est alors de stocker l'ID crypté utilisé sur le côté du client afin qu'il soit enregistré sur le serveur, car tout moyen de stocker le côté serveur informatique entraînera le même problème. J'apprécierais vos commentaires sur celui-là.
@webnoob - S'il s'agit d'un identifiant d'article, je ne me soucierais jamais de le crypter. Les identifiants (comme ici ou tout autre système) ne doivent pas être considérés comme des secrets. Vous devez toujours vérifier sur le serveur si l'utilisateur X a des autorisations sur l'élément Y.
Vous êtes mal compris ce que je dis. Je sais que le serveur vérifie les autorisations; C'est un must. L'OP a changé et depuis été édité, mais le point qu'il faisait était de savoir quel document est édité si une personne modifie la valeur dans un champ masqué, puis vérifiez les autorisations de cet identifiant. Le chiffrement de l'identifiant arrêtera ce champ de changer d'autre que ce que vous attendez, c'est-à-dire. Vous ne pouvez pas simplement changer d'ID 1 en ID 2 au lieu de cela et vous pouvez compter sur le fait que l'ID qui a été transmis n'a pas été altéré.
Il ne devrait pas être basé sur rien soumis par l'utilisateur. Vous devez toujours vérifier les autorisations utilisateur sur le côté serveur. Un attaquant peut préparer n'importe quelle demande à votre serveur.
Vous devez stocker une sorte d'identité au client - sinon, comment sauriez-vous quel élément à modifier?
Cela ne vous libère pas de la vérification Vérifiez sur le serveur que l'utilisateur actuel a des privilèges pour éditer / voir l'élément modifié.
Ensuite, pourquoi, pourquoi voudriez-vous comment il devait éditer l'article (que ce soit par une utilisation légale de l'outil Web ou en modifiant le champ caché / quel que soit le champ).
Je me demande quelle valeur vais-je obtenir si l'ID PARAM ESSET dans GET & POST? qui sera utilisé?
Bien sûr, cela dépendrait de laquelle vous appelez réellement. $ _Post ou $ _GET. Vous pouvez ensuite choisir lequel est utilisé et aussi autant que j'étais au courant avec Global Vars de cette manière n'est pas une bonne idée.
Je pense que cela sera correct de stocker le champ ID dans un champ caché tant que je le contrôle. J'ai en place zend_acl. Sauf que j'utilise $ ceci -> _ getparam () , il semble obtenir des paramètres des deux get and post. Et je viens de tester, quand j'ai des valeurs différentes dans l'obtention et la poste, je vais obtenir d'obtenir. Mais tous ont dit, je pense que tant que j'utilise la même méthode pour obtenir l'identifiant i shld être en sécurité?
En utilisant une sorte de cadre reposant, ce problème se résout; L'identifiant de l'enregistrement étant édité sera inclus dans l'URL. Quelque chose comme une demande postale à / utilisateurs / 123
Comme PPShein dit, le stockage des identifiants sensibles dans un Var caché n'est pas sûr. Souhaitez-vous stocker un mot de passe dans un Var Caché? C'est vraiment facile pour même un pirate informatique novice d'obtenir ces données.
Vous devez vous assurer que tout contrôle d'accès est appliqué par le serveur.
Dans votre cas, vous devez vous assurer que l'utilisateur connecté (celui de la session) est le propriétaire du profil édité. Ou que l'utilisateur qui effectue les modifications a des autorisations pour éditer ce profil (par exemple est un administrateur)
D'accord avec tous les points ci-dessus, mais si vous avez vraiment besoin de stocker quelque chose de clients pour une raison quelconque, vous pouvez toujours chiffrer les données et déchiffrer lorsque vous devez l'utiliser, mais à nouveau, utiliser des sessions serait la meilleure façon de gérer comme ils ne sont pas accessibles côté client.
Cela ne change pas le fait que l'utilisateur peut changer la valeur tho.
Bien sûr et c'est là que la validation du côté serveur est entrée. Si un pirate informatique a changé une valeur dans un identifiant crypté, il ne déchiffrerait plus correctement et vous sauriez donc que quelque chose n'allait pas.
Ensuite, je pense que le cryptage peut ne pas être trop utile dans ce cas car l'identifiant n'est pas un secret. Encrypypt ou non, je devrai encore vérifier si l'utilisateur a accès à la ressource demandée.
En outre, en ce qui concerne votre commentaire sur le message de @ ppshein, je pense que je ne peux pas compter sur un hachage de déchiffrement comme une demande valide. Si vous êtes en quelque sorte, l'utilisateur connaît votre méthode de hachage, il peut créer des hachages valides à utiliser.
L'utilisateur ne le saurait pas. C'est tout le point de cryptage (pas de hachage). Vous avez une clé stockée dans un script quelque part (ou quelque part ailleurs) et vous l'utilisez pour le cryptage et le décryptage. Vous pouvez également avoir différents niveaux de cryptage (jusqu'à 256 bits (peut-être plus, pas sûr - jamais disparu :)) Si vous devez afficher quelque chose de côté client, le cryptage est le meilleur moyen de le faire.
Je sais que l'identifiant n'est pas un secret, le point est que vous arrêtez l'utilisateur de modifier la valeur. Vous savez donc que vous vérifiez les autorisations du côté du serveur de documents correct.