WordPress Error Fix: „Call to undefined function get_header()”
Văd o creștere mare a atacurilor bot care vizează direct fișierele temei. În primul rând, ei obțin URL-ul către directorul temei dvs. Există numeroase modalități prin care un bot poate obține această informație. De exemplu, majoritatea temelor includ active precum fișiere CSS și JavaScript, iar link-ul include URL-ul complet. Așadar, odată ce au URL-ul temei, roboții răi vor face cereri directe pentru fișiere șablon de temă bine cunoscute, cum ar fi index.php
și header.php
. Solicitarea directă a fișierelor șablon poate dezvălui posibile vulnerabilități de securitate, ceea ce se pare că este un vector de atac din ce în ce mai popular. De asemenea, declanșează erorile „Call to undefined function get_header()” (și altele similare). Din fericire, există o rezolvare ușoară.
Site-ul dvs. este vizat?
Pentru a afla dacă site-ul dvs. este lovit de solicitări directe pentru fișiere de temă, puteți verifica jurnalele de acces/erori ale site-ului dvs. Iată câteva exemple din propriile mele jurnale care ar trebui să vă ajute să vedeți ce trebuie să căutați:
<pre>
, nu mai puțin. 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'
Așa că, dacă site-ul dvs. este ținta unor atacuri de tip „direct-template”, veți vedea o MULȚIME de erori de acest tip. În aceste exemple, solicitările sunt pentru index.php
, 404.php
și header.php
. Din analizele mele, majoritatea solicitărilor de șabloane sunt pentru aceste trei fișiere, dar este posibil să le găsiți, de asemenea, scanând pentru alte fișiere WordPress bine-cunoscute, cum ar fi:
/archive.php/wp-includes/rss-functions.php ..various theme template files..various files in the WP Media Library
În principiu, orice solicitare directă pentru un fișier WordPress core, temă sau plugin va declanșa cel mai probabil o eroare, cu excepția cazului în care se iau măsuri adecvate în prealabil. De exemplu, mai târziu vom examina o modalitate ușoară de a opri eroarea „funcție nedefinită”, care, la rândul său, va ajuta la conservarea resurselor prețioase ale serverului și va îmbunătăți securitatea generală a site-ului.
Înțelegerea erorii
Atunci ce este cu erorile fatale „apel la o funcție nedefinită”? Acestea se întâmplă deoarece nucleul WordPress nu este încărcat pentru fișierele șablon încărcate direct.
De exemplu, dacă solicitați direct header.php
, orice funcție de bază, cum ar fi esc_url()
, nu este disponibilă deoarece fișierul este solicitat în afara WordPress.
Ce se întâmplă dacă nu faceți nimic? Ei bine, este posibil ca tema dvs. să fi implementat deja o tehnică similară, sau poate că nu. Care este riscul? În funcție de modul în care tema dvs. este codificată, poate fi posibil ca actorii răi să execute codul în afara contextului, ceea ce poate expune potențiali vectori de atac.
Cum se remediază
Cel mai simplu mod de a preveni acest tip de eroare este de a ieși pur și simplu din script dacă WordPress nu este disponibil. Aceasta este o tehnică PHP veche, dar eficientă, folosită pentru a preveni accesul direct la fișiere:
<?php if (!defined('ABSPATH')) exit; ?>
Se spune simplu: Dacă constanta ABSPATH
nu este definită, atunci ieșiți din script. Acest lucru funcționează deoarece ABSPATH
este definit doar atunci când WordPress este încărcat. Deci, atunci când un robot rău vine și începe să ceară șabloanele temei tale, va primi pur și simplu o pagină goală (răspuns gol) de la server.
Este posibil să fi văzut un cod similar în timpul călătoriilor tale pe WordPress. Împiedicarea accesului direct la scripturi este o parte importantă a securității PHP. Nu doriți ca atacatorii/bots să ruleze scripturi în afara contextului, atunci când nu sunt autorizați și așa mai departe.
Exemplu
Pentru a implementa această tehnică, deschideți orice fișier de temă care este vizat și includeți linia din partea de sus a fișierului. De exemplu, multe șabloane de temă includ antetul înainte de orice alt cod, arată astfel:
<?php get_header(); ?>
După ce adăugați fragmentul „fără acces direct”, veți avea ceva de genul:
<?php if (!defined('ABSPATH')) exit;get_header(); ?>
Cum decideți să formatați codul este în regulă, ideea este să includeți linia ABSPATH înainte ca orice alte funcții să fie apelate.
Bonus
Pentru a merge mai departe, puteți proteja informațiile sensibile despre fișiere prin dezactivarea vizualizărilor de directoare. De exemplu, dacă vizitați directorul părinte al temei dvs. într-un browser, ce vedeți? Dacă vizualizările de directoare sunt activate, veți obține o listă legată a tuturor fișierelor. Nu este bine. Ceea ce ar trebui să vedeți este fie un ecran alb gol, fie un alt răspuns al serverului. Știți, pentru a vă ajuta să vă păstrați informațiile despre fișiere în siguranță.
Există numeroase modalități de a dezactiva vizualizările de directoare. Modul WordPress este de a crea un nou fișier index.php
(gol) în orice director pe care doriți să îl protejați.
index.php
numai dacă NU există deja unul în directorul respectiv. Adică, nu suprascrieți niciun fișier de index existent.Apoi, în index.php
, adăugați următorul cod:
<?php // Silence is golden.
WordPress core folosește această tehnică în diverse directoare. Prin dezactivarea vizualizărilor de directoare deschise, împiedicăm atacatorii să obțină informații despre ce fișiere există pe server. Așadar, este benefică pentru securitate și este o practică recomandată pentru toate directoarele publice, cu excepția cazului în care aveți acoperit cu .htaccess, sau poate aveți motive să procedați altfel și să lăsați vizualizările activate pentru un anumit director.
Gânduri de încheiere
Tehnicile simple descrise în acest articol sunt măsuri de securitate dovedite care vor preveni executarea de cod nesigur și vor împiedica erorile să vă umple jurnalele. Asta înseamnă performanțe și securitate mai bune pentru site-ul dumneavoastră. Chiar dacă nu vă confruntați cu tipul de erori descrise în acest articol, protejarea fișierelor temei și plugin-urilor dvs. de accesul direct este bună pentru securitate.
.