display_errors off: a hibakimenet kikapcsolása éles üzemben

Röviden: Egy éles weboldalon a display_errors = Off a php.ini-be való, a display_startup_errors = Off, a log_errors = On és a webrooton kívüli hibanapló mellett. Ezenkívül a CMS-eknek és keretrendszereknek éles módban kell futniuk, különben a saját hibaoldalaik mutatják a részleteket. php_admin_flag-gel zárolva és minden frissítés után ellenőrizve a hibák a naplóban maradnak a böngésző helyett.

Mit árul el egyetlen hibaüzenet

Egy figyelmeztetés az oldal tetején, egy „Fatal error” a rendelésösszesítő helyett: az ilyen kimenetek ártalmatlannak látszanak. A támadó számára térkép. Teljes fájlútvonalakat, adatbázisok és táblák nevét, használt könyvtárakat és gyakran a PHP-verziót mutatják.

Éppen az olyan helyzetekben, mint a PHP2Shell, amikor tömegesen keresnek sebezhető szervereket, a szervernek a lehető legkevesebbet kell elárulnia magáról. Ez nem zár le rést a PHP-értelmezőben, de megnehezít minden további lépést egy behatolás után, és fáradságosabbá teszi az Ön alkalmazása elleni célzott támadásokat.

Ehhez jön az adatvédelem. A hibaüzenetek kéréseknek részeit tartalmazhatják, például űrlapokból származó e-mail-címeket. Ami egy látogató böngészőjében megjelenik, az már nincs az Ön ellenőrzése alatt.

Az alapértékek nem éles üzemre valók

Sokan abból indulnak ki, hogy a PHP magától elrejti a hibákat. A PHP kézikönyve mást mond: a display_errors beépített alapértéke 1, a display_startup_errors pedig a PHP 8.0 óta szintén alapértelmezetten be van kapcsolva. Csak a mellékelt php.ini-production sablon állítja mindkettőt Off-ra. A kézikönyv a display_errors-t kifejezetten fejlesztési funkciónak nevezi, amelyet internetre kapcsolt rendszereken soha nem szabad használni.

Hogy a szerver az éles sablont használja-e, nem magától értetődő. A konténer-image-ek részben egyáltalán php.ini nélkül indulnak, a tárhelypanelek saját értékeket állítanak be, egy költözés után pedig szívesen a fejlesztési sablont másolják.

display_errors off: a beállítások áttekintése

A következő értékek értelmesek éles szervereken. Az olyan állandók, mint az E_ALL, csak a php.ini-ben működnek; az Apache-konfigurációban a PHP kézikönyve szerint nincs jelentésük, és számként kell megadni őket.

A zend.exception_ignore_args különösen értékes. Enélkül a beállítás nélkül a naplókban és hibaoldalakon lévő stacktrace-ek tartalmazhatják a függvényhívások argumentumait, tehát az éppen feldolgozott jelszavakat vagy tokeneket is.

; a webes SAPI php.ini-je
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/website-fehler.log
error_reporting = E_ALL
html_errors = Off
zend.exception_ignore_args = On
; csak PHP 8.5, átmeneti intézkedés a 8.5.12-re való frissítésig:
; fatal_error_backtraces = 0

Az FPM-poolban a legfontosabb értékeket ezenkívül zárolja, hogy egyetlen alkalmazás se kapcsolhassa vissza őket az ini_set()-tel:

; pl. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[display_errors] = off
php_admin_flag[display_startup_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php/seite1-fehler.log

Utána indítsa újra az adott PHP-szolgáltatást. Hogyan működik pontosan a zárolás, azt a php_admin_value: beállítások zárolása a felülírás ellen cikk magyarázza. Egy teljes alapkonfigurációt a A php.ini biztonságos beállítása útmutatóban talál.

A második kapcsoló: az alkalmazás hibakereső módja

A PHP csak a feladat fele. A modern keretrendszerek maguk fogják el a hibákat, és saját, gyakran nagyon részletes hibaoldalakat mutatnak. Hibakereső módban forráskód-részleteket, konfigurációs értékeket és néha környezeti változókat tartalmaznak. Ezek az oldalak akkor is megjelennek, ha a display_errors ki van kapcsolva a PHP-ban.

Ezért minden alkalmazásnál ellenőrizze a saját kapcsolóját. A WordPressnél ez a WP_DEBUG és a WP_DEBUG_DISPLAY a wp-config.php-ben, a Laravelnél és a Symfonynál az APP_DEBUG és a környezet a .env fájlban, más rendszereknél a gyártói dokumentáció szerinti éles mód. Egy éles rendszeren a hibakereső módnak tartósan ki kell lennie kapcsolva, még a „csak egy pillanatra tesztelésre” is kockázat.

Hogyan kezelik tisztán a hibákat az alkalmazásban, ahelyett hogy elnyomnák őket, azt a Hibák és kivételek a PHP-ban írja le.

Így találja meg a hibakimeneteket, mielőtt mások megteszik

Egyszeri beállítás nem elég. A hibakimenetek frissítések, költözések vagy panelmódosítások után visszatérnek. Egy rövid ellenőrzési menet segít:

1. Az érvényes értékeket webkörnyezetben ellenőrizze, ne csak a parancssorban, például egy rövid időre elhelyezett, majd azonnal törölt ellenőrző fájllal.
2. Minden alkalmazás hibakereső módját ellenőrizze annak konfigurációs fájljában.
3. A kiszolgált oldalakat kutassa át tipikus hibaszövegek után, ahogyan az alábbi kódblokk mutatja.
4. A keresőmotorban egy site: lekérdezéssel a domainjére keressen olyan kifejezésekre, mint a „Fatal error” vagy a „Warning”.
5. Ellenőrizze, hogy a hibanaplóba írnak-e, és hogy nincs-e a webrootban.

# A kiszolgált oldalak átkutatása PHP-hibaszövegek után (csak saját domainek)
for url in https://www.example.de/ https://www.example.de/kontakt/; do
  curl -s "$url" | grep -E -o "(Fatal error|Warning|Notice|Deprecated|Stack trace)[^<]{0,80}" | head -3
done
# Írnak a hibanaplóba?
ls -l /var/log/php/

Összegzés: csendes a böngészőben, bőbeszédű a naplóban

Az éles szerverekre vonatkozó szabály egyszerű: a hibák a naplóba valók, nem a weboldalra. A gyakorlatban az olyan alapértékeken bukik el, amelyek nem éles üzemre valók, az alkalmazások hibakereső kapcsolóin, és a frissítések vagy költözések után visszaeső konfigurációkon.

Aki kikapcsolja a display_errors és a display_startup_errors beállítást, zárolja az értékeket a poolban, ellenőrzi az alkalmazás hibakereső módját, és rendszeresen ellenőrzi az eredményt, az lezárja a szükségtelen információközlés egyik leggyakoribb forrását. A ráfordítás csekély, a hatás megmarad, amíg az ellenőrzés minden frissítés részét képezi.

Egy pont ne vesszen el: a hibanapló nem szemetes. Aki rendszeresen olvassa, felismeri a hibás frissítéseket, az elavult függvényeket, néha pedig egy támadás első nyomait is, jóval azelőtt, hogy az ügyfelek bármit észrevennének.

Hogyan segít konkrétan a PHP SOS?

• Ellenőrzés: Kiolvassuk az érvényes hibabeállításokat weboldalanként és poolonként, és a kiszolgált oldalakat hibakimenetek után kutatjuk át.
• Átállítás: A PHP- és alkalmazásbeállításokat éles üzemre állítjuk, és zároljuk a felülírás ellen.
• Naplók beállítása: A hibanaplók a webrooton kívül vannak, rotálódnak, és a fejlesztői számára hozzáférhetők.
• Tartós megőrzés: A biztonsági karbantartási szerződés keretében minden frissítés után újra ellenőrizzük a beállításokat.

Gyakori kérdések

Források

• PHP kézikönyv: hibakezelés és naplózás
• PHP kézikönyv: a konfiguráció módosítása (php_admin_flag)
• php.net: biztonsági közlemények
• OWASP Cheat Sheets