Articles

WordPress hibajavítás: “Call to undefined function get_header()”

♦ Posted by Jeff Starr in PHP, Security
January 11, 2019

Nagy növekedést látok a témafájlokat közvetlenül célzó bot támadásokban. Először is megszerzik a téma könyvtárának URL címét. Számos módja van annak, hogy egy bot megszerezze ezt az információt. Például a legtöbb téma tartalmaz olyan eszközöket, mint a CSS- és JavaScript-fájlok, és a link tartalmazza a teljes URL-címet. Így aztán, ha már megvan a téma URL címe, a rossz botok közvetlen kéréseket intéznek a jól ismert téma sablonfájlokhoz, mint például a index.php és header.php. A sablonfájlok közvetlen lekérdezése esetleges biztonsági réseket tárhat fel, ami nyilvánvalóan egyre népszerűbb támadási vektor. Emellett kiváltja a “Call to undefined function get_header()” (és hasonló) hibákat. Szerencsére van egy egyszerű megoldás.

Az Ön webhelye célpont?

Hogy megtudja, hogy webhelyét érik-e a témafájlok közvetlen kérései, ellenőrizheti webhelye hozzáférési/hibanaplóit. Íme néhány példa a saját naplóimból, amelyek segítenek megmutatni, hogy mit kell keresni:

Megjegyzés: A következő naplóbejegyzésekben minden fájl elérési útvonalát példa-URL-re változtattam, hogy megakadályozzam a Google lánctalálatát és hibajelzését. A tényleges naplófájlokban a hibák fájl elérési utakat tartalmaznak, nem URL-eket. Utóirat: a legnevetségesebb, hogy a Googlebot egyszerű szöveges elérési útvonal-információkat másol, méghozzá <pre> címkéken belül.
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'

Ha tehát a webhelyét közvetlen sablon-támadások érik, sok ilyen típusú hibát fog látni. Ezekben a példákban a kérések a index.php, 404.php és header.php címekre vonatkoznak. Elemzéseim alapján a legtöbb sablonkérés erre a három fájlra irányul, de előfordulhat, hogy más jól ismert WordPress-fájlokat is keresnek, például:

/archive.php/wp-includes/rss-functions.php ..various theme template files..various files in the WP Media Library

Gyakorlatilag minden közvetlen kérés egy WordPress mag-, téma- vagy bővítményfájlhoz nagy valószínűséggel hibát vált ki, hacsak nem teszünk előzetesen megfelelő intézkedéseket. Később például megnézzük, hogyan lehet egyszerűen megállítani az “undefined function” hibát, ami viszont segít megőrizni az értékes szerver erőforrásokat és javítani az oldal általános biztonságát.

A hiba megértése

Szóval, mi van a “call to undefined function” végzetes hibákkal? Ezek azért fordulnak elő, mert a WordPress mag nem töltődik be a közvetlenül betöltött sablonfájlokhoz.

Ha például közvetlenül a header.php fájlt kéri, akkor az olyan core funkciók, mint a esc_url() nem állnak rendelkezésre, mert a fájlt a WordPressen kívül kéri.

Mi történik, ha nem tesz semmit? Nos, lehet, hogy a témád már megvalósított egy hasonló technikát, de az is lehet, hogy nem. Mi a kockázat? Attól függően, hogy a témád hogyan van kódolva, lehetséges, hogy a rosszfiúk kontextuson kívül hajtanak végre kódot, ami potenciális támadási vektorokat tárhat fel.

Hogyan javítsd

A legegyszerűbb módja az ilyen típusú hibák megelőzésének, ha egyszerűen kilépsz a szkriptből, ha a WordPress nem elérhető. Ez egy ősi, mégis hatékony PHP-technika, amelyet a közvetlen fájlhozzáférés megakadályozására használnak:

<?php if (!defined('ABSPATH')) exit; ?>

Ez egyszerűen így szól: Ha a ABSPATH konstans nincs definiálva, akkor lépj ki a szkriptből. Ez azért működik, mert a ABSPATH csak akkor van definiálva, amikor a WordPress betöltődik. Így amikor jön egy rossz bot, és elkezdi kérni a téma sablonjait, egyszerűen egy üres oldalt (üres választ) fog kapni a szervertől.

Valószínűleg találkoztál már hasonló kóddal a WordPress utazásaid során. A közvetlen szkript-hozzáférés megakadályozása a PHP biztonságának fontos része. Nem akarod, hogy a támadók/botok szkripteket futtassanak kontextuson kívül, jogosulatlanul, és így tovább.

Példa

A technika megvalósításához nyisd meg a célzott témafájlokat, és vedd fel a fájl tetejére a sort. Például sok téma-sablon tartalmazza a fejlécet minden más kód előtt, így néz ki:

<?php get_header(); ?>

A “nincs közvetlen hozzáférés” snitt hozzáadása után valami ilyesmi lesz:

<?php if (!defined('ABSPATH')) exit;get_header(); ?>

Hogyan is döntesz a kód formázásáról, a lényeg, hogy az ABSPATH sort minden más függvény meghívása előtt szerepeltesd.

Pro tipp: Szeretnél még több rossz botot megállítani? Nézze meg a WP Plugin Directoryban elérhető ingyenes WordPress pluginomat, a Blackhole for Bad Bots-t.

Bónusz

Az érzékeny fájlinformációkat a könyvtárnézetek letiltásával még tovább védheti. Ha például meglátogatod a téma szülői könyvtárát egy böngészőben, mit látsz? Ha a könyvtárnézetek engedélyezve vannak, akkor egy összekapcsolt listát kapsz az összes fájlról. Ez nem jó. Amit látnia kellene, az vagy egy üres fehér képernyő, vagy valamilyen más szerver válasz. Tudod, hogy a fájladatok biztonságban legyenek.

A könyvtárnézetek letiltásának számos módja van. A WordPress módja az, hogy létrehoz egy új (üres) index.php fájlt abban a könyvtárban, amelyet védeni szeretnél.

Fontos! Csak akkor hozzon létre új index.php fájlt, ha még NEM létezik a könyvtárban. Vagyis ne írja felül a meglévő indexfájlokat.

Ezután a index.php-be írja be a következő kódot:

<?php // Silence is golden.

A WordPress core ezt a technikát használja különböző könyvtárakban. A nyitott könyvtárak megtekintésének letiltásával megakadályozzuk, hogy a támadók információt szerezzenek arról, hogy milyen fájlok léteznek a szerveren. Ez tehát előnyös a biztonság szempontjából, és ajánlott gyakorlat minden nyilvános könyvtár esetében, kivéve, ha a .htaccess segítségével megoldottad, vagy esetleg más okod van rá, és engedélyezve hagyod a nézeteket egy adott könyvtár esetében.

Záró gondolatok

A cikkben leírt egyszerű technikák olyan bevált biztonsági intézkedések, amelyek megakadályozzák a nem biztonságos kódfuttatást, és megakadályozzák, hogy a hibák megtömjék a naplóidat. Ez jobb teljesítményt és biztonságot jelent webhelye számára. Még ha nem is tapasztalja az ebben a cikkben leírt típusú hibákat, a téma- és bővítményfájlok védelme a közvetlen hozzáféréstől jót tesz a biztonságnak.

Jeff Starr

A szerzőről
Jeff Starr = Designer. Fejlesztő. Producer. Writer. Szerkesztő. Etc.