Je suis en fait un ingénieur chez VIP qui fait beaucoup de révision de code :) Je signale beaucoup d'échappements manquants.
mais n'échappe pas à la sortie
Pas tout à fait, il ne s'échappe pas en sortie, ce qui surprend la plupart des gens. En effet, si vous êtes un super administrateur, vous en avez la unfiltered_htmlcapacité, il ne peut donc pas s'échapper en sortie. Au lieu de cela, il l'exécute wp_kses_posten entrée. Idéalement, vous supprimeriez cette capacité.
Voici l'implémentation à l'heure actuelle:
function the_content( $more_link_text = null, $strip_teaser = false ) {
$content = get_the_content( $more_link_text, $strip_teaser );
/**
* Filters the post content.
*
* @since 0.71
*
* @param string $content Content of the current post.
*/
$content = apply_filters( 'the_content', $content );
$content = str_replace( ']]>', ']]>', $content );
echo $content;
}
Le mécanisme idéal pour échapper à tout ce qui passe à travers le the_contentfiltre est d'autre part:
echo apply_filters( 'the_content', wp_kses_post( $content ) );
De cette façon, nous sécurisons le contenu, puis le passons à travers le filtre, en évitant que les intégrations, etc. soient supprimées.
Alors pourquoi s'échapper
Le point de fuite est de générer du HTML valide, la sécurité supplémentaire qu'il offre n'est qu'un bel effet secondaire.
Pour empêcher les utilisateurs de rompre accidentellement le balisage
Il y a de nombreuses raisons de s'échapper, mais fondamentalement, vous faites respecter les attentes. Prenez le code suivant:
<a href="<?=$url?>">
Nous nous attendons $urlà contenir une URL adaptée à un hrefattribut, mais que faire si ce n'est pas le cas? Eh bien, pourquoi le laisser au hasard, permet de le faire respecter:
<a href="<?=esc_url( $url )?>">
Ce sera désormais toujours une URL. Peu importe si un pirate met une image $urldedans, si un utilisateur tape dans le mauvais champ, ou s'il y a un script malveillant. Ce sera toujours une URL valide, car nous avons dit que ce serait une URL. Bien sûr, il peut s'agir d'une URL très étrange, mais elle répondra toujours à l'attente qu'une URL soit là. C'est très pratique, que ce soit pour la validation du balisage, pour la sécurité, etc.
Cela dit, l'évasion n'est pas une validation, l'évasion n'est pas une désinfection. Ce sont des étapes distinctes qui se produisent à différents moments du cycle de vie. S'échapper oblige les choses à répondre aux attentes, même si cela les empêche de le faire.
Parfois, j'aime penser à m'évader comme l'un de ces jeux japonais avec le mur de mousse géant avec la découpe. Les concurrents doivent s'adapter à la forme du chien ou ils sont jetés, seulement pour nos fins il y a des lasers et des couteaux autour du trou. Tout ce qui restera à la fin sera en forme de chien, et il sera impitoyable et strict si vous n'êtes pas déjà en forme de chien.
Rappelles toi:
- désinfecter tôt
- valider tôt
- s'échapper tard
- s'échapper souvent
La sécurité est une étape multiple, un oignon multicouche de défenses, l'évasion est l'une des couches externes de défense en sortie. Il peut perturber le code d'attaque sur un site compromis, le rendant inutile, contrecarrer les exploits ouverts et s'assurer que votre client ne casse pas un site en mettant des balises dans un champ qu'il ne devrait pas. Ce n'est pas un substitut pour les autres choses, et c'est de loin l'outil de sécurité le plus sous-utilisé dans le manuel du développeur.
Quant à savoir pourquoi s'échapper si ce the_contentn'est pas le cas? Si vous avez une inondation à venir et 5 trous dans un mur, mais seulement le temps de réparer 3, haussez-vous les épaules et n'en réparez-vous pas? Ou atténuez-vous le risque et réduisez-vous la zone d'attaque?
Je peux peut-être aider à réparer ces 2 derniers trous avec cet extrait:
add_filter( 'the_content' function( $content ) {
return wp_kses_post( $content );
}, PHP_INT_MAX + 1 );
Ici, nous fixons la priorité au nombre le plus élevé possible en PHP, puis ajoutons 1 pour qu'il déborde au plus petit nombre possible qui peut être représenté. De cette façon, tous les appels à the_contentéchapperont à la valeur avant tout autre filtre. De cette façon, les intégrations, etc. fonctionnent toujours, mais les utilisateurs ne peuvent pas s'introduire dans du code HTML dangereux via la base de données. En outre, envisagez de supprimer la unfiltered_htmlcapacité de tous les rôles
wp_kses_post