web-dev-qa-db-fra.com

Quel est le moyen le plus sûr de générer du code JavaScript et CSS personnalisé entré par l'administrateur dans les paramètres de thème?

Je crée un thème dans lequel j'ai créé des options permettant à l'administrateur d'entrer un code Javascript et CSS personnalisé dans la page "Paramètres du thème" (créée à l'aide de l'API Options).

Maintenant, je ne suis pas sûr de savoir comment sortir ce code de la meilleure façon possible. Pour le Css, j'ai décidé d'utiliser wp_add_inline_style() et de mettre à jour un fichier css. Pour JavaScript, je répète le code avant la balise wp_footer(), comme ceci:

if ( $custom_js != '' ) { ?>
  <script id="theme-custom-js">
    <?php echo $custom_js; ?>
  </script>
<?php }
<?php wp_footer(); ?>

Tout cela fonctionne très bien, mais je ne suis pas sûr d’utiliser des fonctions d’échappement avant d’ajouter simplement le fichier css au fichier ou d’envoyer en écho ce que l’utilisateur a entré.

J'ai essayé esc_html, esc_js et wp_json_encode, mais évidemment, ils sont censés faire le contraire.

Je comprends que le code devrait être sûr puisqu'il provient supposément de l'administrateur, mais c'est juste que j'ai pris des mesures extrêmes tout au long de mon thème et que j'ai essayé d'échapper à presque tout avant même qu'il ne soit répercuté. Donc, je sens juste que je devrais en quelque sorte faire la même chose avec ça.

S'il vous plaît faites le moi savoir à ce sujet et merci beaucoup.

2
user1981248

Permettre à l'utilisateur de contrôler le code est une opération explicitement dangereuse. Comme vous le constatez, le but de la désinfection est plutôt de ne pas laisser l’utilisateur glisser quoi que ce soit d’exécutable et/ou avec une intention malveillante.

Pour "désinfecter" le code exécutable, vous avez besoin d'une compréhension programmatique de celui-ci (analyseur de code) et d'un moteur de critères afin de distinguer ce qui est sûr ou non. Pour de telles exigences, c'est utopique.

Nativement, WordPress permet à l'administrateur d'utiliser JavaScript dans le contenu d'un article. De temps en temps, les gens le signalent comme "une vulnérabilité de sécurité horrible", mais en réalité, il s'agit simplement d'une question de confiance binaire - vous pouvez faire confiance à un utilisateur pour saisir du code exécutable ou vous ne le ferez pas. Il n’existe essentiellement aucun moyen terme ou "mais pas ce code" dans ce cas.

2
Rarst