web-dev-qa-db-fra.com

Qu'en est-il si j'écris AJAX fonctions utilisant wp-load.php?

Ma question est la suivante: lorsque j'écris une fonction AJAX, je peux l'écrire à l'aide d'un fichier séparé. Je peux inclure wp-load.php dans ce fichier et utiliser WP fonctions de base. Je sais que c'est faux. Pouvez-vous me dire à quel point c'est mauvais? Est-ce un gros risque pour la sécurité? Quels sont les risques et inconvénients de sécurité?

theme-developmentajax
6
Dhanuka Nuwan

C'est incroyablement mauvais et, dans un trou de sécurité majeur, vous devrez faire face à ces problèmes:

  • Votre point de terminaison sera toujours , même si votre plugin est désactivé ou si vous changez de thème.
  • Votre point de terminaison sera actif sur tous les sites d'une installation multisite, pas seulement ceux pour lesquels vous l'avez conçu, ce qui peut entraîner l'utilisation du point de terminaison à des endroits non prévus.
  • Le fichier sera fragile. Si vous déplacez votre dossier de plugins ou mettez le plugin dans mu-plugins, le système d'extrémité générera 500 erreurs irrécupérables.
  • Vous devrez implémenter vous-même toutes les authentifications et validations
  • Les plugins de mise en cache ne pourront pas interagir avec votre point de terminaison, ce qui ralentira le traitement des demandes courantes.
  • Ce point de terminaison peut acceptern'importe quoiet il pourrait renvoyern'importe quoi

Ce serait un euphémisme de dire que les terminaux autonomes dans les thèmes et les plugins sont un risque pour la sécurité, qu’il s’agisse d’un gestionnaire AJAX ou d'un gestionnaire de formulaire, voire d'un fichier autonome pour les images (timthumb l'a fait et même le fichier d'origine). les développeurs l'ont désavoué en raison de sa réputation de sécurité)

Vous pouvez utiliser l'API WP AJAX, qui est préférable, mais vous oblige à implémenter vous-même les vérifications d'authentification ou de désinfection, et présente quelques défauts. Il ne fournit également aucune structure, car avec un terminal standard, il peut tout recevoir et tout retourner (s'il retourne du tout).

Au lieu de cela, utilisez l'API REST avec register_rest_route, il est plus facile à utiliser, a moins de bizarreries et gère l'authentification pour vous. Il vous donne également des URL et un espacement de noms plus conviviaux, par exemple:

function tomjn_rest_test() {
        return "moomins";
}
add_action( 'rest_api_init', function () {
        register_rest_route( 'tomjn/v1', '/test/', array(
                'methods' => 'GET',
                'callback' => 'tomjn_rest_test'
        ) );
} );

Vous pouvez le voir sur:

https://tomjn.com/wp-json/tomjn/v1/test

Avec cela, je peux faire un certain nombre de choses:

  • spécifier que l'utilisateur doit être connecté et exactement ce dont il a besoin pour pouvoir le faire
  • spécifier les arguments
    • spécifier le type et l'assainisseur pour chaque argument séparément
    • spécifier si elles sont nécessaires ou non
  • spécifier si un noeud final est destiné à la lecture/écriture ou aux deux

Tous sont gérés par un code écrit pour le noyau. Bien sûr, vous pouvez implémenter tout cela vous-même manuellement dans chaque WP AJAX gestionnaire, mais cela est beaucoup plus concis et testé (et il y en a peu dans le WP communauté suffisamment expérimentée pour le faire correctement), par exemple pour que mon point final ci-dessus ne soit disponible que pour les administrateurs:

register_rest_route( 'tomjn/v1', '/test/', array(
    'methods' => 'GET',
    'callback' => 'tomjn_rest_test',
    'permission_callback' => function( $req ) {
        return current_user_can('manage_options');
    }
) );

En prime, certaines meilleures pratiques sont beaucoup plus faciles à utiliser, telles que le renvoi de données non HTML, l'utilisation standard de HTTP GET PUT POST, etc., et renvoie une réponse JSON pouvant être validée.

Pourquoi un point d'extrémité est-il toujours actif?

J'ai mentionné précédemment qu'un point de terminaison natif est actif, même si le plug-in qu'il contient est désactivé. Le seul moyen de le désactiver consiste à effectuer des contrôles internes ou à supprimer le fichier. Pourquoi est-ce si mauvais?

Le noeud de ceci est que ce qui pourrait être approprié dans une circonstance peut ne pas l'être dans une autre.

Par exemple, scénario 1:

Un administrateur installe un plug-in qui permet aux utilisateurs de se connecter et de s'inscrire sur le front-end sans actualiser la page. Pour ce faire, le plug-in a un noeud final pour créer des utilisateurs. Cependant, l’administrateur réalise que l’enregistrement n’est pas ce qu’il voulait, mais se connecte et désactive le plug-in. Les fichiers sont toujours présents et les utilisateurs peuvent toujours charger le noeud final pour créer de nouveaux utilisateurs.

Scénario 2:

Un plugin est utilisé sur une installation multisite pour envoyer des emails à l'administrateur d'un blog via un formulaire de contact. Tout fonctionne comme prévu, mais il existe d'autres blogs sur le site qui ne s'intéressent pas à cette fonctionnalité. En modifiant le domaine utilisé pour le blog, un attaquant peut envoyer des e-mails aux administrateurs de ces autres blogs en chargeant le point de terminaison utilisé par le formulaire de contact dans le contexte des autres blogs du réseau, en envoyant des e-mails à toute personne disposant d'un rôle d'administrateur. n'importe où sur l'installation multisite

Scénario 3:

Un plugin a une fonctionnalité de débogage utile qui permet aux utilisateurs de modifier leurs courriels, mais pour des raisons de sécurité, vous avez désactivé cette fonctionnalité. Toutefois, le noeud final qui gère le formulaire de modification de courrier électronique est un fichier autonome. Toute personne connaissant la structure du formulaire peut toujours modifier son courrier électronique.

8
Tom J Nowell

Le principal inconvénient de l'écriture d'un noeud final de fichier personnalisé est que votre fichier ne sait pas où wp-load.php est généralement le cas. Lorsque vous êtes dans WP environnement, le contexte vous est fourni. Si vous essayez de trouver où WP core à partir d'un fichier PHP arbitraire, il ne fonctionnera pas pour toutes les configurations possibles.

Donc, le principal inconvénient de cette technique est qu'elle ne peut pas être distribué dans des extensions publiques.

7
Rarst