Bir tanılama sayfası ya da kayıt dosyası herkese açık

ÖnemOrta

KapsamTüm site

EmekAz

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

Kural anahtarısec_exposed_debug

Kısa cevap

Sitenizde herkesin açabildiği bir tanılama sayfası ya da kayıt dosyası var: phpinfo() çıktısı, Apache'nin /server-status sayfası ya da bir PHP debug.log dosyası. phpinfo dosyasını silin, kayıtları herkese açık web klasörüne yazmayı bırakın ve server-status'ı yalnız kendi IP adresinize açın.

Neden önemli

phpinfo() tam PHP sürümünü, yüklü her eklentiyi, sunucudaki dosya yollarını ve ortam değişkenlerini yazdırır; bazı barındırmalarda bu değişkenler veritabanı ya da API kimlik bilgilerini içerir. Apache server-status o anda sunulan istekleri tam adresleriyle (şifre sıfırlama ve giriş linkleri dahil) ve ziyaretçi IP adresleriyle listeler. WordPress'in debug.log dosyası dosya yolları, eklenti adları, SQL parçaları ve bazen e-posta adresleri içeren uyarıları biriktirir.

Otomatik tarayıcılar bu bilinen adları buldukları her sitede dener; sürüm bilgisi saldırganın sunucunuza uyan bir istismarı seçmesini sağlar. Sıralamaya doğrudan etkisi yoktur, ancak herkese açık bir kayıt dosyası dizine alınıp içeriğiyle arama sonuçlarında görünebilir.

Glimana bunu nasıl tespit eder

Glimana HTTPS ana makinenizde beş sabit adresi ister: /phpinfo.php, /info.php, /server-status, /debug.log ve /wp-content/debug.log; her birinin yalnız ilk 2 KB'ını okur. Bir dosya ancak yanıt 200 ya da 206 olduğunda ve içerik eşleştiğinde sayılır: phpinfo başlığı ya da "PHP Version x.y" satırı, Apache Server Status sayfası ya da PHP biçiminde kayıt satırları ([07-Nov-2026 10:00:00 UTC] PHP Warning: …, HTML olmayan bir yanıtta). Var olmayan rastgele bir adresin yanıtıyla aynı olan cevap sitenizin hata sayfası sayılır ve yok sayılır. Her eşleşme adresleriyle birlikte orta önemle bildirilir; eşleşme türü dışında hiçbir şey saklanmaz.

Nasıl düzeltilir

Dikkat

WP_DEBUG_LOG açıkken wp-content/debug.log dosyasını silmek yetmez: WordPress dosyayı bir sonraki uyarıda yeniden oluşturur. Kaydı kapatın ya da web kökünün dışındaki bir yola yönlendirin. Ayrıca .htaccess kurallarının Nginx sunucularda hiçbir etkisi olmadığını unutmayın.

Glimana'da bulguyu bulun. Güvenlik sayfasını açın; bu kontrol Açıkta kalan dosyalar grubunda, son taramanın kanıtı başlığının altında. Aynı sorun Sorunlar › Bir tanılama sayfası ya da kayıt dosyası herkese açık altında da listelenir.
Düzeltmeyi platformunuzda uygulayın.

WordPressApache / LiteSpeedNginx

wp-config.php dosyasında, "That's all, stop editing" satırının üstünde define( 'WP_DEBUG', false ); ve define( 'WP_DEBUG_LOG', false ); ayarlayın. Kayda ihtiyacınız varsa ona gizli bir yol verin: define( 'WP_DEBUG_LOG', '/home/kullanici/logs/wp-debug.log' ); (WordPress 5.1+). Ardından barındırma firmanızın dosya yöneticisi ya da SFTP ile wp-content/debug.log dosyasını ve site kökünde kalmış phpinfo.php ya da info.php dosyalarını silin.

server-status'ı sunucu yapılandırmasında kısıtlayın:
<Location "/server-status"> SetHandler server-status Require ip 203.0.113.10 </Location>
(IP'yi kendinizinkiyle değiştirin ya da Require local kullanın). Yerinde kalması gereken bir kayıt dosyasını engellemek için .htaccess dosyasına ekleyin: <Files "debug.log"> Require all denied </Files>. phpinfo dosyalarını gizlemek yerine silin.

Nginx .htaccess dosyasını okumaz. server bloğuna location ~* /debug\.log$ { deny all; } ekleyin, phpinfo dosyalarını silin, ardından nginx -t && systemctl reload nginx çalıştırın. Nginx'in arkasında Apache çalışıyorsa onun server-status sayfasını Apache sekmesindeki gibi kısıtlayı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üzeltmeden sonra Güvenlik sayfasında Yeniden tara düğmesine basın (ya da pazar 04:00'teki haftalık taramayı bekleyin); kontrol geçtiğinde sorun kapanır.