Quels sont les inconvénients de l'utilisation de PHP Filtrer le code dans les blocs, les nœuds, les vues-arguments, etc.?
J'ai vu à plusieurs reprises des gens dire de ne pas utiliser de filtre PHP/PHP personnalisé (à partir de l'interface utilisateur Drupal) dans les blocs, les nœuds, les vues-arguments, les règles, etc. J'ai cherché un peu et je n'ai pas trouvé beaucoup, il semble que ce soit une Drupal meilleure pratique que tous "savent juste".
Je comprends que cela pose un risque potentiel pour la sécurité, en particulier entre les mains des utilisateurs finaux ou des nouveaux utilisateurs de Drupal ou PHP, mais en tant que développeur/constructeur de site, quelles sont les vraies raisons de ne pas utiliser de _ personnalisé [PHP à partir de l'interface utilisateur Drupal?
Certaines raisons:
- Le code dans votre base de données ne peut pas être contrôlé par la version et est également plus difficile à trouver en général plus tard.
- Le code d Eval () est beaucoup plus lent que quelque chose codé en dur dans un fichier.
- S'il y a une erreur quelque part dans ce code, vous obtiendrez un message d'erreur très inutile (erreur dans le code eval () d à la ligne 3) et vous pourriez même avoir à parcourir manuellement votre base de données pour trouver et corriger l'erreur. S'il se trouve à l'intérieur d'un bloc qui s'affiche sur toutes les pages et entraîne une erreur fatale tout le temps par exemple.
- Ce qui précède est également vrai lors de la mise à niveau de Drupal 6 à 7 et quelles que soient les API que vous avez utilisées ont été modifiées. Vous devrez donc porter votre code lors de la migration. Si le code est dans un module, vous pouvez le porter à l'avance, le tester et le déployer uniquement sur le nouveau site. À l'intérieur d'un nœud ou d'un bloc, il ne fonctionnera qu'avec Drupal 6 ou 7.
- Écrire et maintenir ce code est également plus difficile, car vous travaillez dans un champ de texte à l'intérieur de votre navigateur. Le faire dans un module vous permet d'utiliser un éditeur/IDE avec coloration syntaxique, saisie semi-automatique, etc.
- Il y a toujours la possibilité d'une mauvaise configuration qui donne aux gens l'accès à un format de texte/bloc/peu importe avec l'exécution php activée. Si php.module (en D7, D6 n'est pas aussi strict, par exemple pour les règles d'accès aux blocs) n'est même pas activé, ce risque est déjà beaucoup plus faible.
- Si votre CMS permet l'exécution de PHP alors un attaquant qui trouve une vulnérabilité de sécurité de XSS ou une élévation de privilèges peut maintenant utiliser votre serveur pour des choses extrêmement malveillantes (dans le cadre d'un DDOS, envoi de spam, hébergement de malware) , piratage vers d'autres sites/bases de données sur le serveur, piratage vers d'autres serveurs du réseau qui pourraient être derrière des pare-feu). En plus de rendre les petites vulnérabilités plus douloureuses, cela fait du site une cible d'attaque plus probable si l'on sait qu'il peut être utilisé pour exécuter php.
Il pourrait y avoir plus de raisons, mais cela devrait suffire :)
Ce code est difficile à déboguer et à maintenir. Je ne connais aucun moyen d'utiliser le contrôle de version pour ce type de code PHP.
Et c'est vraiment un risque potentiel pour la sécurité des nouveaux utilisateurs de Drupal ou PHP,
Compte tenu du cas du filtre PHP utilisé dans un nœud, la raison de ne pas l'utiliser est que vous limitez les utilisateurs qui peuvent modifier ce nœud, si vous ne voulez pas autoriser tous les utilisateurs pour utiliser le filtre PHP.
Plutôt que d'utiliser le filtre PHP, il est préférable d'utiliser un module personnalisé qui remplace un texte spécifique dans le contenu du nœud par le résultat du code qu'il exécute (sans utiliser eval()), ou qui ajoute son propre texte au contenu du corps des nœuds. Dans ce cas, tout utilisateur peut modifier le nœud, sans avoir la permission d'ajouter arbitraire PHP code qui est ensuite exécuté par le filtre PHP.
En règle générale, il vaut mieux éviter eval() car cela diminue la lisibilité du code, la possibilité pour vous de prédire le chemin du code (et les éventuelles implications de sécurité de celui-ci) avant l'exécution, et donc la possibilité de déboguer le code .
En dehors d'un site de développement ou de test, je n'activerais pas le filtre PHP, ni utiliser PHP transmis à eval() .
Le filtre PHP a été supprimé de Drupal 8. Il est maintenant n module tiers , non couvert par le - politique d'avis de sécurité . C'est probablement une raison de plus pour ne pas l'utiliser dans les serveurs de production (si les raisons déjà données ne vous ont pas convaincu).
Voici la raison de la vulnérabilité de sécurité pour éviter d'accorder cette autorisation à vos utilisateurs si vous ne souhaitez pas que vos utilisateurs non administrateurs modifient directement la base de données.
<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>
Pour contourner les différents problèmes spécifiés ci-dessus - difficulté de maintenance du code, contrôle de version, recherche d'erreurs, vous avez cette possibilité légèrement "klugey":
Créez des fonctions (nommez-les soigneusement, en fonction de ce qu'elles font) dans un fichier qui est toujours inclus - si vous avez un module personnalisé que vous écrivez pour le site, c'est un excellent endroit pour mettre ces fonctions. Le php que vous entrez alors est simplement: return my_specialfunc($somevar); - $somevar ici étant potentiellement l'objet nœud travaillé, ou toute autre variable pertinente ici.
Je trouve que je veux toujours la flexibilité, à certains endroits, d'appeler mon propre code. En utilisant cette technique, la maintenance du code est facile car il s'agit simplement de modifier la fonction dans le fichier. Le repérage des erreurs est facile car la fonction apparaîtra dans une trace.
Notez cependant que cela ne résout pas les problèmes de sécurité potentiels. Celles-ci dépendent largement de la sécurité du noyau Drupal. En général, le code contenu dans la base de données est souvent le talon de la sécurité des achillees - les fonctionnalités utilisant du code contenu dans la base de données ont tendance à être beaucoup plus sujettes à l'exploitation et la sécurité autour d'eux doivent être très strictes. Cependant, Drupal a en général été assez bon pour maintenir la sécurité pour ces problèmes - ils sont apparus puis rapidement corrigés/résolus avec de nouvelles versions .
Plutôt que de faire quelque chose comme return functionname($object), il serait préférable d'utiliser le système de jetons/filtres dans la mesure du possible. Il existe des modules comme Insert View et Embed Node) qui peuvent aider dans des circonstances courantes dans lesquelles les gens voudraient incorporer PHP dans les corps de nœuds ou de blocs.
Vous devez vous soucier de la portabilité de vos données. Que faire si vous migrez vos nœuds de drupal 7 vers drupal 8 et que le texte du corps de certains nœuds contient <?php whatever_function_that_does_not_exist_anymore(); ?>)?
Ne pensez pas à votre projet dans les 5 mois mais dans les 5 ans. Les mises à jour, les bonnes pratiques et la portabilité sont des aspects importants de tout bon projet informatique à mon avis.
L'utilisation de modules aussi peu contribués que possible en est également un aspect.