Dans quels contextes les plugins sont-ils responsables de la validation / désinfection des données?

15

Je veux m'assurer que toutes les données de mes plugins / thèmes sont traitées de manière sécurisée avant d'entrer dans la base de données et avant d'être envoyées au navigateur. Mon problème est qu’il existe des situations dans lesquelles l’API gère la désinfection pour vous - comme lors de la sauvegarde de méta-champs de publication - et dans laquelle l’auteur du plugin / thème en est entièrement responsable - comme lors de la sauvegarde de paramètres personnalisés.

En ce qui concerne le champ d'application de cette question, la validation des données au niveau du domaine ne me concerne pas, par exemple, la vérification qu'un champ Âge d'un formulaire est compris entre 0 et 120, ou qu'une adresse électronique est valide. La sécurité me préoccupe uniquement - par exemple, échapper des requêtes SQL pour éviter l'injection SQL lors de l'enregistrement dans la base de données, ou nettoyer les données qui sont générées dans des modèles HTML pour éviter XSS.

Pour la désinfection de sortie, je sais que vous devez toujours utiliser des fonctions telles que esc_html() et esc_attr() lorsque vous transformez des variables en modèles HTML. Mais qu'en est-il de l'utilisation des balises de modèle ? Est-ce qu'ils tous déjà assainissent la sortie? Si oui, pour quel contexte (HTML général, attributs de balises, etc.)? Certaines fonctions ont des variantes pour différents contextes (comme the_title_attribute() , mais la plupart n’en ont pas.

Pour la désinfection des entrées, je sais que je dois utiliser $wpdb->prepare() lorsque je pose des requêtes manuellement, mais qu’en est-il de l’utilisation de l’API de configuration pour créer une page de paramètres de plug-in ou de l’enregistrement de champs de méta pour un type de publication personnalisé?

Pour le moment, je viens de fouiller dans le Core et lire des didacticiels chaque fois que j'utilise une fonction pour savoir si elle désinfecte ou non, mais cela prend du temps et génère des erreurs. J'espère trouver une sorte de liste complète de toutes les situations possibles et savoir si l'API le gère ou non. par exemple,

L'API valide / assainit

  • Enregistrement de méta de messages avec update_postmeta()
  • Enregistrement de la méta de l'utilisateur avec update_user_meta()
  • Sortie d'un titre d'article - utilisez la variante appropriée à votre contexte de the_title()
  • etc

Vous devez valider / assainir manuellement

  • Enregistrement des options de plug-in avec l’API de configuration. Transmettez un rappel en tant que troisième paramètre de register_setting() .
  • Requêtes directes dans la base de données: encapsulez la requête dans $wpdb->prepare() .
  • Sortie des variables en HTML. Utilisez esc_attr() , esc_html() , etc.
  • etc

J'aimerais aussi comprendre pourquoi l'API le fournit dans certaines situations, mais pas dans d'autres. Je suppose que cela a quelque chose à voir avec la nature inconnue des données, mais j'aimerais entendre une explication détaillée.

    
posée Ian Dunn 06.09.2012 - 21:48

2 réponses

15

Il y a deux concepts ici:

  • validation - s’assurer que les données sont valides , c’est-à-dire qu’un entier est un entier, une date est une date (au bon format, etc.). Cela devrait être fait juste avant de sauvegarder les données.
  • sanitisation - rendre la date sûre pour son utilisation dans le contexte actuel (par exemple, échapper des requêtes SQL ou échapper du HTML sur la sortie).

La validation est, presque universellement, à vous de décider . Vous savez quelles données vous demandez à un utilisateur et quelles données vous attendez - WordPress ne le sait pas. La validation serait effectuée, par exemple, sur le hook save_post avant de l’enregistrer dans la base de données avec update_post_meta , ou bien en spécifiant une fonction de rappel dans l’API de configuration, appelée juste avant que WordPress enregistre les données.

L’assainissement est un peu plus mélangé. Lorsque vous traitez avec des données que WordPress connaît nativement (par exemple, une mosaïque de publication), vous pouvez être sûr que WordPress a déjà sécurisé les données. Cependant, "sûr" dépend du contexte; ce qui est sûr pour une utilisation sur une page, n'est pas nécessairement sûr en tant qu'attribut d'élément. Par conséquent, WordPress aura différentes fonctions pour différents contextes (par exemple, the_title() , the_title_rss() , the_title_attribute() ) - vous devez donc utilisez le bon .

Dans la plupart des cas, votre plug-in peut traiter des données post-méta ou peut-être des données d'événement d'une table personnalisée. WordPress ne sait pas ce que sont ces données ni ce à quoi elles servent, alors il ne sait certainement pas comment les sécuriser. Cela vous appartient . Ceci est particulièrement important lorsque vous utilisez esc_url() , esc_attr() , esc_textarea() , etc., afin d'empêcher les entrées malveillantes d'incorporer du code. WordPress sachant que next_posts() est supposé imprimer une URL sur la page, il applique esc_url() - mais avec post meta, par exemple, il ne sait pas qu'il stocke une URL - ni ce que vous voulez en faire (si impression, esc_url() , si vous redirigez esc_url_raw() . Si vous êtes dans le dobut, évitez les erreurs et les précautions vous-même - et faites-le le plus tard possible.

Enfin, qu'en est-il de la sauvegarde des données? Avez-vous besoin de le rendre sûr alors? Comme mentionné, vous devez vous assurer que les données sont valides. Mais si vous utilisez l'API WordPress ( wp_insert_post() , update_post_meta() etc.), vous n'avez pas besoin de purifier les données - car lors de la sauvegarde des données, la seule purification à effectuer est d'échapper aux instructions SQL - et WordPress le fait. Si vous exécutez des instructions SQL directes (par exemple, pour lire / écrire des données d’une table personnalisée), vous devez utiliser le $wpdb classe pour vous aider à nettoyer vos requêtes.

J'ai écrit ce article de blog sur la purification et la validation des données que vous pourriez trouver utile - je parle de ce que l’on attend de vous à cet égard.

    
réponse donnée Stephen Harris 07.09.2012 - 01:06
0

Je ne suis pas sûr que ce soit si complet, mais avec n'importe quel plugin ou thème, les entrées de l'utilisateur doivent être vérifiées. Les opérations de base de données doivent être effectuées à l'aide de la commande $ wpdb- > méthodes. Toutes les données $ _GET et $ _POST doivent être désinfectées.

C’est une meilleure pratique pour la programmation PHP que WordPress.

Donc, en conclusion, s’il existe une fonction WordPress, utilisez-la, sinon, désinfectez vous-même vos variables et entrées.

Si j'étais trop vague, posez une question plus précise.

    
réponse donnée Ciprian 06.09.2012 - 23:06

Lire d'autres questions sur les étiquettes