web-dev-qa-db-fra.com

La vérification de la sécurité dans la méta_box save est réticente?

Par exemple, dans de ce tutoriel , le code suggéré lors de la sauvegarde des données de la boîte à méta est

/* Verify the nonce before proceeding. */
if ( !isset( $_POST['smashing_post_class_nonce'] ) || !wp_verify_nonce( $_POST['smashing_post_class_nonce'], basename( __FILE__ ) ) )
    return $post_id;

/* Get the post type object. */
$post_type = get_post_type_object( $post->post_type );

/* Check if the current user has permission to edit the post. */
if ( !current_user_can( $post_type->cap->edit_post, $post_id ) )
    return $post_id;

Les vérifications de nonce et user role semblent réticentes, elles semblent reliées au save_post, qui correspond presque à la dernière ligne de la fonction wp_insert_post, WordPress devrait déjà avoir effectué les vérifications nécessaires, n'est-ce pas?

Pour que je puisse les enlever en toute sécurité?

pluginscustom-fieldmetaboxsecuritynonce
1
Yoga

Non, pas vraiment. Vous supposez que la fonction appelée wp_insert_post() a déjà effectué ces vérifications. Mais wp_insert_post() peut également être utilisé dans d'autres pages, pas seulement dans la page d'édition, par des plugins ou même par des thèmes (beaucoup d'entre eux présentant des failles de sécurité).

C'est pourquoi vous devez vous assurer que votre code ne tourne que là où vous voulez en utilisant le nonce.

Ok je modifie la réponse car la réponse du commentaire serait trop longue.

Si un plugin expose wp_insert_post, ce n'est pas seulement que mon nouveau champ personnalisé sera piraté, c'est que tous les champs de publication seront piratés. (à nouveau, c'est le bogue dans le plugin) Donc, je ne peux vraiment pas voir que vérifier mon propre champ personnalisé peut apporter une sécurité supplémentaire

Mais cela serait "piraté" avec l'aide de votre code. Pensez au formulaire de post rapide sur la maison du tableau de bord. Il n'a pas de champs de saisie pour votre méta de publication, n'est-ce pas? Lors de la soumission, wp_insert_post -> save_post est appelé et si $_POST contient vos champs méta (il est facile d’éditer la source et d’en ajouter), ils seront enregistrés avec votre code de boîte méta. Essentiellement, si vous ne faites pas de contrôles nonce, cela vous permet de changer vos champs méta à partir de n’importe quel formulaire WordPress impliquant une post-édition, pas seulement celui auquel vous avez attaché vos champs d’entrée personnalisés. c'est ce que tu veux?

Je ne crée PAS une nouvelle action, donc si le code du wordpress principal permet d'appeler wp_insert_post sans vérifier le nonce, il s'agit d'un bogue dans WP. (Comme vous pouvez le voir, ils ont tous appelé le check_admin_referer dans le post.php.

L'objectif de wp_insert_post est d'insérer des publications et non de vérifier d'où proviennent les données. Cependant, je conviens que l'action save_post était mal placée. De telles fonctions ne doivent en aucun cas déclencher des actions et des filtres. Au lieu de cela, l'action aurait dû être déclenchée par chaque gestionnaire de soumission de formulaire. Outre le fait que cette action introduit davantage d'incohérences dans l'API WP, elle facilite également les exploits ...

4
onetrickpony