Nincs kitett hibaüzenet

Ha egy PHP-hiba, egy adatbázis-hiba vagy egy hibakövetési lista (stack trace) megjelenik az oldalon, abból a támadó megtudja a fájlútvonalakat, az adatbázis szerkezetét és a használt szoftvereket. Az OWASP hibakezelési ajánlása szerint váratlan hibánál általános választ kell adni a látogatónak, a részleteket pedig a szerver oldalán kell naplózni.

A php.net a display_errors beállításról kimondja, hogy fejlesztést támogató funkció, és éles rendszeren soha nem szabad használni.

Hogyan mérjük

A riport két oldalt vizsgál meg: a kezdőoldalt, és egy szándékosan nem létező címet (/hellowp-report-404-<véletlen>, legfeljebb 3 átirányítással). Mindkét oldal törzsének legfeljebb az első 512 KB-ját nézi át. A teszt kétállapotú: ha egyik oldalon sincs találat, megfelelő; ha bármelyiken van, hiba. Ha egyik oldal törzse sem érhető el, a teszt nem értékelhető, és kimarad a pontszámból.

A teszt ezeket a mintákat keresi:

• PHP-hiba, HTML-formázva: <b>Warning</b>: ... in <b>fájl</b> on line <b>12</b> (a Warning, Notice, Fatal error, Deprecated vagy Parse error szóval).
• PHP-hiba, sima szövegként: Warning: ... in /útvonal/fájl.php on line 12, elöl akár PHP előtaggal (ugyanezekkel a szavakkal).
• SQL-hiba: SQLSTATE[...] vagy You have an error in your SQL syntax.
• Hibakövetés: Stack trace: #0 vagy Uncaught Exception / Uncaught Error, de csak akkor, ha a közelében (300 karakteren belül) PHP-fájl és sor is áll (.php:12, .php(12) vagy on line 12).

Amit a teszt nem számít:

• A <script>, <pre>, <code> és <textarea> elemek tartalmát figyelmen kívül hagyja, mert ott kódpéldák és JS-szövegek szoktak lenni.
• A talált szöveget nem tárolja, a riportban csak a fajta (PHP, SQL, hibakövetés) látszik.

Amit nem lát: a bejelentkezés mögötti oldalakat, az űrlapok beküldése utáni hibákat, és azokat az aloldalakat, amelyeken a hiba csak bizonyos feltételnél jelentkezik.

Hogyan javítsd

1. Kapcsold ki a hibák megjelenítését az éles oldalon.
2. Kapcsold be a naplózást, hogy a hibák ne vesszenek el. A php.net szerint a log_errors alapértéke 0, tehát külön be kell kapcsolni.
3. Ha a hiba egy bővítményből vagy a témából jön, a naplóból derítsd ki az okát, és javítsd vagy frissítsd. A WordPress hibakeresésről a WordPress hibakeresés és naplózás oldalon olvashatsz.

WordPress

A wp-config.php fájlba, a /* That's all, stop editing! */ sor elé (a WordPress dokumentációja szerint ez a hely a hibakereső állandóknak):

wp-config.php

define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

A WordPress dokumentációja szerint a WP_DEBUG_DISPLAY alapértéke true, vagyis alapból kiírja a hibákat az oldalba; false értékkel ez kikapcsol. Ha a fájlban már van WP_DEBUG_DISPLAY sor, azt írd át, ne vegyél fel mellé újat. A naplózáshoz a WP_DEBUG_LOG szolgál (a WP_DEBUG bekapcsolt állapotában).

Bedrock esetén a WP_ENV környezeti változó dönt a viselkedésről; a Roots dokumentációja szerint, ha nincs megadva, a Bedrock production értéket használ. Éles oldalon legyen production.

PHP (php.ini)

php.ini

display_errors = Off
log_errors = On

A php.net szerint a php.ini-production mintafájl a display_errors értékét Off-ra állítja. A beállítást kérheted a tárhelytől is.

Más rendszer vagy saját alkalmazás

Az alkalmazás hibakezelőjének általános oldalt kell visszaadnia, a részleteket pedig naplóznia (OWASP). A keretrendszerek éles és fejlesztői módja külön beállítás, nézd meg a saját dokumentációját.

Hogyan ellenőrizd

Futtasd újra a riportot. Kézzel is megnézheted a két vizsgált oldalt: nyisd meg a kezdőoldalt és egy nem létező címet, és nézd meg, látsz-e fájlútvonalat, on line szöveget vagy SQL-hibát. Ha a hibát egy bejelentkezés mögötti oldal okozza, azt a riport nem fogja meglátni, ott te ellenőrizd.