Vaut-il la peine de restreindre l'accès direct aux fichiers de thème?

J'ai rencontré de temps en temps l'extrait de code suivant dans les thèmes:

if ( ! defined('ABSPATH')) exit('restricted access');

C'est au début de certains (tous?) Fichiers PHP dans un thème et il est censé empêcher l'accès direct au fichier par des sources malveillantes.

Je vois que cela n'est pas inclus dans Twenty Ten ou Eleven et je ne l'ai jamais vu recommandé dans la documentation officielle de WordPress. Cela me semble être une bonne idée, mais je ne connais pas assez la sécurité pour en juger et je ne trouve pas grand chose avec Google.

Est-ce quelque chose que je devrais avoir dans mes thèmes personnalisés? Si tel est le cas, devrait-il figurer dans tous les fichiers PHP ou seulement dans certains?

theme-development security

— mrwweb
source

Juste pour les lecteurs ultérieurs, cela peut être écrit plus court et plus agréable:defined('ABSPATH') OR exit;

— kaiser

ou encore plus court:: defined('WPINC') ? : die();P

— Tim Elsass

Je me demande également s'il vaut la peine de mettre du code comme celui-ci juste pour éviter de voir les erreurs PHP concernant les fonctions non définies dans mes journaux d'erreurs. Les bots semblent parfois toucher directement ces fichiers et j'obtiens des erreurs comme «Appel à la fonction undefined query_posts ()» parce que le bootstrap WP n'a pas été chargé

— Matt Keys

Habituellement, vous n'en avez pas besoin. Mais… il y a au moins un cas de bord:

Si un fichier de thème est une partie de modèle ,
et il utilise des variables globales du contexte appelant (fichier parent),
et register_globals est on,
et il utilise simplement ces variables sans aucun contrôle de sécurité…

… Un attaquant peut appeler ce fichier, définir les variables manquantes avec GETou POSTet faire imprimer le fichier de thème. Et puis il y a un problème de sécurité.

Donc… la meilleure option n'est pas une vérification de contexte comme celle de votre exemple, mais un bon code: évitez les variables globales, vérifiez leur contenu avant de l'imprimer.

Dans certains cas, j'ajoute la vérification de contexte lorsque je pense que quelqu'un d'autre utilisera mon code et le modifiera sans sécurité. Ça ne fait pas mal.

— fuxia
source

Si une partie de modèle contenait toujours au moins un appel de fonction qui provoquerait une erreur fatale PHP, ce scénario serait-il toujours possible?

— Chris_O

@Chris_O Dépend de l'ordre d'apparition.

— fuxia

Il est logique et totalement d'accord sur une autre raison de ne pas utiliser de variables globales entre les appels de fichiers.

— Chris_O

Il vaut toujours mieux prévenir que guérir. Trop de sécurité ne peut pas nuire, n'est-ce pas?

— Sean Berg

Si vous faites tout correctement, vous ne devez pas utiliser de code inutile. Cette question est la preuve qu'elle rend le code plus difficile à suivre.

— fuxia