web-dev-qa-db-fra.com

Est-il prudent de stocker un paramètre utilisateur que vous ne souhaitez pas que l'utilisateur modifie en tant qu'option utilisateur?

J'ai ajouté des options utilisateur personnalisées à la page de profil de mon site, et la plupart permettent à l'utilisateur de se modifier lui-même. Ces options vivent dans leur propre section. Les utilisateurs ont un accès en lecture et sont en mesure de visiter le backend et de modifier certains paramètres de leurs profils.

Il existe une autre option par utilisateur que je ne souhaite pas que l'utilisateur puisse modifier directement. J'ai le code qui crée ce groupe d'options et cette section qui vérifie si l'utilisateur peut éditer les profils des autres utilisateurs. S'ils ne le peuvent pas, la section et le paramètre ne sont pas enregistrés avec WordPress (et ne sont donc pas affichés sur la page de profil). Seule une personne disposant de l'autorisation appropriée peut accéder à la page de modification du profil, afficher et modifier les paramètres via le backend.

Un utilisateur malveillant peut-il jamais soumettre des données POST supplémentaires avec une mise à jour du profil valide par ailleurs et définir une option qui n'a pas été enregistrée sur la page, mais qui existe dans la base de données? Comment certain/solide est cette protection? Y at-il des problèmes connus avec cela?

custom-fielduserssecurityoptionsprofiles
6
jeremiahs

Vous devez (si disponible) soumettre le code avec lequel vous travaillez, même s'il ne s'agit que d'un extrait, afin que nous puissions évaluer votre processus par rapport à votre question.

La réponse courte est cependant OUI, il est sûr, tant que vous,

  • empêche l'affichage de champs de saisie sur la page de profil de l'utilisateur pour certains rôles d'utilisateur
  • empêche les utilisateurs non autorisés de sauvegarder les méta-utilisateurs dans la base de données

Premier:

Si les champs de saisie qui se rapportent aux métadonnées de l'utilisateur sont masqués de rôles d'utilisateur spécifiques sur la page de profil de l'utilisateur, "l'attaquant" doit alors deviner quel est le meta_key pour le champ dans lequel ils souhaitent peupler. Bonne chance avec ça!

Deuxième à cela:

S'ils pouvaient deviner le meta_key en question, ils auraient alors besoin d'exécuter des fonctions relatives à update_user_meta ou add_user_meta. La seule façon de le faire est si,

  • ils peuvent voir les champs de saisie
  • vous avez omis de vérifier les capacités de l'utilisateur via des instructions conditionnelles.

... ce qui permettrait alors à l'utilisateur de sauvegarder ou d'éditer les méta-champs de l'utilisateur qui devraient sinon être caché non ajouté/rendu à la demande à l'écran.

Nous supposerons que

  • vous ne fournissez aucun autre moyen aux utilisateurs d'exécuter des scripts arbitraires de leur choix ailleurs sur votre site

... ce qui atténue le risque qu'une attaque se produise en premier lieu.

Un début serait d'encapsuler les fonctions liées à l'ajout ou à l'édition de métadonnées utilisateur dans la fonction current_user_can .

if ( current_user_can('edit_users') ) {

    //show input fields function

    //allow input fields to be updated function
}

Ceci vérifie si l'utilisateur actuel peut réellement edit_users lequel est disponible par défaut uniquement pour les super administrateurs et les administrateurs sauf si vous avez autrement autorisé cette fonctionnalité à un autre rôle d'utilisateur de votre choix.

Ce n’est pas le seul contrôle que vous voudrez peut-être effectuer, mais c’est certainement l’un des plus importants à inclure pour la sécurité.

6
userabuser