Correction d’erreur WordPress : « Appel à la fonction indéfinie get_header() »
Je vois une grande augmentation des attaques de robots ciblant directement les fichiers de thème. D’abord, ils obtiennent l’URL de votre répertoire de thème. Il existe de nombreuses façons pour un bot d’obtenir cette information. Par exemple, la plupart des thèmes comprennent des actifs tels que des fichiers CSS et JavaScript, et le lien inclut l’URL complète. Ainsi, une fois qu’ils ont l’URL du thème, les robots malveillants font des demandes directes pour les fichiers de modèle de thème bien connus, comme index.php et header.php. La demande directe de fichiers de modèles peut révéler d’éventuelles failles de sécurité, ce qui est apparemment un vecteur d’attaque de plus en plus populaire. Cela déclenche également les erreurs « Call to undefined function get_header() » (et similaires). Heureusement, il existe un correctif facile.
Votre site est-il visé ?
Pour savoir si votre site est frappé par des demandes directes de fichiers de thème, vous pouvez vérifier les journaux d’accès/d’erreurs de votre site. Voici quelques exemples tirés de mes propres journaux qui devraient vous montrer ce qu’il faut rechercher:
<pre>, rien de moins.2018-12-30 17:54:07 ErrorAH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to undefined function get_header() in https://example.com/wp-content/themes/digwp/index.php:1Stack trace: #0 {main} thrown in https://example.com/wp-content/themes/digwp/index.php on line 1'2018-12-30 12:53:55 ErrorAH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to undefined function get_header() in https://example.com/wp-content/themes/digwp/404.php:1Stack trace: #0 {main} thrown in https://example.com/wp-content/themes/digwp/404.php on line 1'2018-12-30 12:53:55 ErrorAH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to undefined function esc_url() in https://example.com/wp-content/themes/digwp/header.php:8Stack trace: #0 {main} thrown in https://example.com/wp-content/themes/digwp/header.php on line 8'Donc, si votre site est la cible d’attaques directes de modèles, vous verrez BEAUCOUP de ces types d’erreurs. Dans ces exemples, les requêtes sont pour index.php, 404.php, et header.php. D’après mes analyses, la plupart des requêtes de templates concernent ces trois fichiers, mais vous pouvez également les trouver en train de scanner d’autres fichiers WordPress bien connus, tels que :
/archive.php/wp-includes/rss-functions.php ..various theme template files..various files in the WP Media LibraryBasiquement, toute requête directe pour un fichier de base, de thème ou de plugin WordPress déclenchera très probablement une erreur, à moins que des mesures appropriées soient prises au préalable. Par exemple, plus tard, nous examinerons un moyen facile d’arrêter l’erreur » fonction indéfinie « , ce qui, à son tour, aidera à conserver les précieuses ressources du serveur et à améliorer la sécurité globale du site.
Comprendre l’erreur
Alors, qu’est-ce que les erreurs fatales » appel à une fonction indéfinie » ? Elles se produisent parce que le noyau de WordPress n’est pas chargé pour les fichiers de modèle directement chargés.
Par exemple, si vous demandez directement header.php, toutes les fonctions du noyau telles que esc_url() ne sont pas disponibles parce que le fichier est demandé en dehors de WordPress.
Que se passe-t-il si vous ne faites rien ? Eh bien, votre thème peut déjà avoir mis en œuvre une technique similaire, ou peut-être pas. Quel est le risque ? Selon la façon dont votre thème est codé, il peut être possible pour les mauvais acteurs d’exécuter du code hors contexte, ce qui peut exposer des vecteurs d’attaque potentiels.
Comment corriger
La façon la plus simple d’empêcher ce type d’erreur est de simplement quitter le script si WordPress n’est pas disponible. Il s’agit d’une technique PHP ancienne mais efficace utilisée pour empêcher l’accès direct aux fichiers :
<?php if (!defined('ABSPATH')) exit; ?>Il dit simplement : si la constante ABSPATH n’est pas définie, alors quittez le script. Cela fonctionne parce que ABSPATH n’est défini que lorsque WordPress est chargé. Ainsi, quand un mauvais bot arrive et commence à demander les modèles de votre thème, il obtiendra simplement une page blanche (réponse vide) du serveur.
Vous avez peut-être vu un code similaire au cours de vos voyages WordPress. Empêcher l’accès direct au script est une partie importante de la sécurité de PHP. Vous ne voulez pas que les attaquants/robots exécutent des scripts hors contexte, lorsqu’ils ne sont pas autorisés, et ainsi de suite.
Exemple
Pour mettre en œuvre cette technique, ouvrez tous les fichiers de thème qui sont ciblés, et incluez la ligne en haut du fichier. Par exemple, de nombreux modèles de thèmes incluent l’en-tête avant tout autre code, ressemble à ceci:
<?php get_header(); ?>Après avoir ajouté le snippet « pas d’accès direct », vous aurez quelque chose comme:
<?php if (!defined('ABSPATH')) exit;get_header(); ?>La façon dont vous décidez de formater le code est très bien, le point est d’inclure la ligne ABSPATH avant que toute autre fonction soit appelée.
Bonus
Pour aller plus loin, vous pouvez protéger les informations de fichiers sensibles en désactivant les vues de répertoire. Par exemple, si vous visitez le répertoire parent de votre thème dans un navigateur, que voyez-vous ? Si les vues de répertoire sont activées, vous obtiendrez une liste liée de tous les fichiers. Ce n’est pas bon. Ce que vous devriez voir, c’est un écran blanc ou une autre réponse du serveur. Vous savez, pour aider à garder vos informations de fichiers en sécurité.
Il existe de nombreuses façons de désactiver les vues de répertoire. La méthode WordPress consiste à créer un nouveau fichier index.php (vide) dans le répertoire que vous souhaitez protéger.
index.php que s’il n’en existe PAS déjà un dans le répertoire. Autrement dit, n’écrasez pas les fichiers d’index existants.Puis dans index.php, ajoutez le code suivant :
<?php // Silence is golden.Le noyau de WordPress utilise cette technique dans divers répertoires. En désactivant l’affichage des répertoires ouverts, nous empêchons les attaquants d’obtenir des informations sur les fichiers qui existent sur le serveur. Cela profite donc à la sécurité et c’est une pratique recommandée pour tous les répertoires publics, à moins que vous ne l’ayez couvert avec .htaccess, ou que vous ayez peut-être des raisons de faire autrement et de laisser les vues activées pour un répertoire spécifique.
Pensées finales
Les techniques simples décrites dans cet article sont des mesures de sécurité éprouvées qui empêcheront l’exécution de code non sécurisé et empêcheront les erreurs de remplir vos journaux. Cela signifie de meilleures performances et une meilleure sécurité pour votre site. Même si vous ne rencontrez pas le type d’erreurs décrites dans cet article, protéger vos fichiers de thème et de plugin de l’accès direct est bon pour la sécurité.
