web-dev-qa-db-fra.com

Désinfection et validation des données avec la fonction apply_filters ()

Devons-nous désinfecter et valider leapply_filters()comme dans les exemples ci-dessous?

  1. absint( apply_filters( 'slug_excerpt_length', 35 ) );

  2. wp_kses_post( apply_filters( 'slug_excerpt_more', '…' ) );

  3. esc_url( apply_filters( 'slug_login_url', home_url( '/' ) ) );

Je pose cette question, parce que je n'ai jamais vu cela auparavant. En fait, nous ajoutons une validation pour éviter de casser quelque chose lorsque l'utilisateur ajoute quelque chose de mal dans le thème enfant.

Je me demande ce que vous en pensez.

filtersvalidationsanitizationescaping
7
Asaf

Il y a une certaine confusion ici, car toutes ne sont pas de la validation, il en faut 2 autres pour comprendre ce qui est approprié:

  • validation
  • assainissement
  • s'échapper

Assainissement

La désinfection rend les choses propres et bien formés

Cela nettoie les données, par exemple rognage des espaces de fin, suppression des lettres dans un champ numérique, création d'un champ tout en minuscule, tout en minuscule, etc.

Par exemple. L'utilisateur a entré " Banana ", alors transformez-le en "Banana"

La désinfection est la première chose qui devrait arriver à entrée qui vient d’ailleurs, par exemple. lors du traitement d'un formulaire, désinfectez les données avant de les utiliser. La même chose de toutes les données provenant d'une connexion à distance, etc.

Les méthodes d'assainissement populaires incluent:

  • supprimer HTML ou des balises particulières via wp_kseswp_strip_all_tags etc.
  • Suppression de plages de caractères, telles que des caractères non numériques ou de la ponctuation
  • Découper des caractères de fin tels que des espaces, etc.
  • Application de limites telles que la restriction de valeurs dans une plage (ceci pourrait plutôt être implémenté comme contrôle de validation)

Validation

La validation vérifie si les choses sont valides

La validation vérifie que le numéro de téléphone saisi par l'utilisateur est en réalité un numéro de téléphone. C'est un chèque true ou false.

Par exemple. Le fruit que l'utilisateur a choisi est-il réellement un fruit?

Ceci devrait être fait sur input après la désinfection, et si la validation échoue, abandonnez, les méthodes de validation courantes incluent:

  • fonctions comme is_numeric etc
  • expressions régulières, utiles pour des choses comme les numéros de téléphone ou les URL, qui ont un format attendu
  • vérification des rôles et des fonctionnalités pour vérifier que l'utilisateur a réellement la capacité de réaliser l'action souhaitée
  • contrôles nonce
  • listes blanches de valeurs autorisées prédéfinies
  • les valeurs de contrôle se situent dans les plages valides, par exemple personne n'a un numéro de téléphone long de 200 caractères, et personne ne vivrait dans le numéro de maison -2000000

S'échapper

Échapper rend les valeurs sûres pour la sortie, et applique des hypothèses

Evadez-vous tard, évadez-vous souvent.

Echapper ne parle pas beaucoup, mais imaginez-le en utilisant l'exemple du fruit d'en haut. S'échapper est comme un tapis roulant avec une découpe en forme de fruit. Vous obtenez toujours quelque chose de fruit en forme à la fin. Si un fruit passe à travers, il est intact, mais si un acteur malveillant passe à travers, une version en forme de fruit mutilé mais sans danger ressort à la fin.

S'échapper est donc une question de mise en application des hypothèses. Par exemple. dans une balise <a>, l'attribut href doit contenir une URL. Mais ce n'est peut-être pas le cas, échapper nous permet d'échanger le "devrait contenir" contre un "contiendra toujours", en nous fournissant une garantie. Cela évite que quelqu'un commence son URL avec "/> et insère du code HTML arbitraire.

L'échappement doit toujours être effectué sur output , au plus tard, pour ne rien modifier. Echapper est également sensible au contexte. Vous utiliseriez esc_attr pour échapper aux attributs HTML, mais s'il s'agit d'un attribut href ou src, nous utiliserions esc_url pour indiquer qu'il s'agit d'une URL que nous avons l'intention de générer.

Une note sur Double Escaping et wp_kses

Vous pouvez désinfecter et valider plusieurs fois, mais vous ne devez échapper une fois qu'une valeur. Cela est dû au fait que le double échappement peut doubler le codage des valeurs et, dans certaines circonstances, permettre au contenu de s'échapper.

wp_kses_post et wp_kses sont également inhabituels en ce qu'ils peuvent être utilisés pour s'échapper, et pour désinfecter, et peuvent être utilisés plusieurs fois sur une valeur.

Une note sur les premiers échappés

C'est un péché presque mortel qui peut presque annuler tout ce qui vous échappe. Une fois que quelque chose a été échappé, nous savons qu'il est sûr de le sortir, mais , si nous l'attribuons ensuite à une variable, qui sait ce qui pourrait lui arriver entre échappement et sortie. Si cette variable est modifiée, transmise à une fonction ou transmise via un filtre, ce n'est plus sans danger, son statut est un mystère. Nous pouvons y échapper mais maintenant nous avons échappé deux fois; nous avons donc peut-être rendu des données sécurisées dangereuses ou des données endommagées.

Donc, à propos de ces filtres

Devons-nous désinfecter et valider la apply_filters() comme dans les exemples ci-dessous?

Ça dépend du contexte

En entrée:

  • Désinfecter
  • puis valider
  • si c'est valide alors continuez, sinon rejetez

À la sortie du navigateur/demande/etc:

  • vous pouvez supprimer et valider une fois extraite de la base de données si vous le souhaitez, mais la priorité n ° 1 consiste à s'échapper, échapper une seule fois, et le faire au moment de la sortie. Ne le stockez pas dans une variable, c'est une fuite anticipée et c'est dangereux
  • Échapper après le filtrage, pas avant, qui sait ce que le filtre a fait avec une valeur sûre connue, une fois que la valeur est renvoyée du filtre, sa sécurité et son statut sont un mystère
  1. absint( apply_filters( 'slug_excerpt_length', 35 ) );

Nous savons maintenant que cette valeur est certainement un nombre, et un nombre positif également. Si nous préfixons cette instruction avec echo, il s'agit d'une valeur échappée sûre. Sinon, ce n'est que la désinfection qui en a nettoyé la valeur.

  1. wp_kses_post( apply_filters( 'slug_excerpt_more', '&hellip;' ) );

Génial, c’est à la fois une désinfection et une évasion si nous l’envoyons immédiatement, mais si nous l’enregistrons dans une variable, c’est une désinfection.

  1. esc_url( apply_filters( 'slug_login_url', home_url( '/' ) ) );

Cela s'échappe et nécessite une instruction echo. Si nous affectons cela à une variable, l'échappement est nul et nous introduisons une situation précaire.

Si la question est en revanche, devrions-nous vérifier deux fois les valeurs de retour des filtres? Oui, ce serait sage, mais trop prudent. Dans ce scénario, je m'attendrais à ce qu'il s'agisse de tester des filtres qui ne sont pas implémentés correctement, par exemple. renvoyer le texte où un nombre est attendu. Dans ce scénario, la validation est la seule option, échapper et la désinfection serait inapproprié.

Exceptions

  • Lorsque vous utilisez le filtre the_content, transmettez la valeur à travers wp_kses_post, puis transmettez-la au filtre et obtenez immédiatement un écho, par ex. echo apply_filters( 'the_content', wp_kses_post( $dangerous ) );
  • Dans les codes courts, échappez et utilisez les tampons de sortie si vous le devez pour pouvoir renvoyer une chaîne.
16
Tom J Nowell