Hata mesajları iç ayrıntıları gösteriyor

ÖnemOrta

KapsamTüm site

EmekAz

DoğrulamaGüvenlik taraması (haftalık ya da Yeniden tara)

Kural anahtarısec_error_disclosure

Kısa cevap

Glimana'nın yüklediği bir sayfada Warning: ... in /home/account/public_html/wp-content/plugins/x/file.php on line 42 gibi ham bir hata, bir yığın izi (stack trace) ya da bir altyapı hata ayıklama sayfası görünüyor. Canlı sitede hataların ekranda gösterilmesini kapatın, hataları web kökü dışındaki bir dosyaya yazdırın ve ardından hatanın kendisini düzeltin. Bu metni ziyaretçiler ve arama motorları da görür.

Neden önemli

Hata çıktısı saldırgana sunucunun klasör yapısını, barındırma hesabının adını, eklenti ve dosya adlarını, bazen de veritabanı sorgularını ya da ayar değerlerini verir. Bir altyapı hata ayıklama sayfası (APP_DEBUG=true olan Laravel) hata tetikleyen herkese veritabanı parolaları ve API anahtarları dahil ortam değişkenlerini gösterebilir. Dosya yolları dosya dahil etme gibi başka saldırıları da çok daha kolay hedeflenir hale getirir.

Metin ziyaretçilere ve Googlebot'a da ulaşır: düzeni bozabilir, arama snippet'lerine girebilir ve genellikle sayfada bir şeyin çalışmadığını gösterir.

Glimana bunu nasıl tespit eder

Glimana ana sayfanızın ve en çok iki başka sayfanın HTML'ine sunulduğu haliyle bakar; hata oluşturmaya çalışmaz. Dosya yolu ve satır numarası içeren bir PHP hata mesajı (Fatal error, Parse error, Warning, Notice ya da Deprecated), bir PHP yığın izi, Laravel'in "Whoops, looks like something went wrong" sayfası ya da bir Illuminate\…Exception sınıf adı bulursa Orta olarak bildirir. Sorun adresi ve kısa bir alıntıyı gösterir.

Nasıl düzeltilir

Dikkat

WordPress WP_DEBUG_LOG çıktısını varsayılan olarak wp-content/debug.log dosyasına yazar ve engellenmedikçe bu dosyayı herkes indirebilir; kütüğe web kökü dışında bir yol verin. Laravel'de ayarlar önbelleğe alınmışsa .env değişikliği, php artisan config:cache yeniden çalıştırılana kadar etki etmez.

Glimana'da bulguyu bulun. Güvenlik sayfasını açın; bu kontrol Bilgi sızıntıları grubunda, son taramanın kanıtı başlığının altında. Aynı sorun Sorunlar › Hata mesajları iç ayrıntıları gösteriyor altında da listelenir.
Düzeltmeyi platformunuzda uygulayın.

WordPressPHPLaravel

wp-config.php dosyasında That's all, stop editing satırının üstüne: define('WP_DEBUG', false);. Canlı sitede kütük tutmanız gerekiyorsa bunun yerine define('WP_DEBUG', true);, define('WP_DEBUG_DISPLAY', false);, define('WP_DEBUG_LOG', '/home/account/logs/wp-errors.log'); ve @ini_set('display_errors', '0'); kullanın. Barındırıcınız display_errors ayarını sunucu düzeyinde açıyorsa PHP ayarını da uygulayın.

php.ini, .user.ini ya da barındırma panelinizin PHP seçeneklerinde: display_errors = Off, display_startup_errors = Off, log_errors = On ve error_log = /home/account/logs/php-errors.log (web kökü dışındaki bir klasör). PHP-FPM'i yeniden başlatın ya da .user.ini dosyasının yeniden okunmasını bekleyin (varsayılan olarak 5 dakikada bir).

Canlı sunucudaki .env dosyasında: APP_ENV=production ve APP_DEBUG=false, ardından php artisan config:cache. Hatalar yine storage/logs/ altına yazılır. Hata ayıklama çubuğu gibi araçları canlı ortamda erişim denetimi olmadan açık bırakmayın.
Glimana'da kontrol edin. Güvenlik sayfasında Yeniden tara düğmesine basın (saatte en çok iki tarama) ya da pazar günkü haftalık taramayı bekleyin; kontrol geçince sorun kapanır.

Düzeltme nasıl doğrulanır

Düzelttikten sonra Güvenlik sayfasında Yeniden tara düğmesine basın (ya da pazar günkü haftalık taramayı bekleyin); kontrol geçtiği anda sorun kapanır.