Test dosyalarını canlı sunucuda unutmak hangi açıkları doğurur?

Canlı ortamda unutulan test dosyaları çoğu zaman küçük bir ihmal gibi görünür; ancak saldırganlar için uygulamanın iç yapısını, veritabanı bağlantılarını, hata çıktılarının detaylarını ve yönetim alışkanlıklarını gösteren değerli ipuçlarıdır. Özellikle web sitesinin yayınlandığı hosting ortamında erişim kuralları doğru ayrılmadıysa, basit bir deneme dosyası yetkisiz erişimden veri sızıntısına kadar ciddi riskler doğurabilir.

Canlı sunucuda kalan test dosyaları neden risklidir?

Geliştirme sürecinde oluşturulan test.php, info.php, debug.php, db-test.php, mail-test.php gibi dosyalar genellikle hızlı kontrol amacıyla hazırlanır. Sorun, bu dosyaların çoğu zaman güvenlik standardı düşünülmeden yazılmasıdır. Hata gösterimi açık bırakılır, kimlik doğrulama eklenmez veya geçici şifreler düz metin içinde yer alır.

Arama motorları, botlar ve otomatik zafiyet tarayıcıları bu tür dosya adlarını düzenli olarak dener. Dosya herkese açık dizindeyse, saldırganın onu bulması için siteyi özel olarak hedeflemesi bile gerekmez.

En sık oluşan güvenlik açıkları

Hassas bilgilerin ifşa olması

PHP bilgi sayfaları, ortam değişkenleri, yüklü modüller, sunucu sürümü, dosya yolları ve yapılandırma detayları hakkında fazla bilgi verebilir. Bu bilgiler tek başına saldırı olmayabilir; fakat saldırganın doğru yöntemi seçmesini kolaylaştırır. Örneğin eski bir PHP sürümü, zayıf bir eklentiyle birlikte daha hızlı istismar edilebilir.

Veritabanı bağlantı bilgilerinin görünmesi

Geliştiriciler bağlantı testleri için kullanıcı adı, parola, veritabanı adı ve sunucu adresini geçici dosyalara yazabilir. Dosya çalışmasa bile hata çıktısı bu bilgilerin bir kısmını gösterebilir. Bu durumda sadece web uygulaması değil, veritabanı katmanı da risk altına girer.

Yetkisiz işlem ve komut çalıştırma

Bazı test dosyaları e-posta gönderme, dosya yükleme, önbellek temizleme veya API deneme amacıyla oluşturulur. Eğer bu dosyalar kullanıcı doğrulaması olmadan çalışıyorsa, dışarıdan tetiklenebilir. Basit bir form test dosyası bile spam gönderimine, sahte üyelik akışlarına veya disk alanının dolmasına neden olabilir.

Hata mesajları üzerinden keşif yapılması

Canlı sunucuda ayrıntılı hata gösterimi açık kaldığında dosya yolları, sınıf adları, framework yapısı ve sorgu detayları görülebilir. Bu bilgiler, saldırganın uygulamanın nasıl geliştirildiğini anlamasına yardımcı olur. Kurumsal projelerde bu durum marka güvenini de zedeler; çünkü kullanıcılar teknik hata çıktısını profesyonel olmayan bir işaret olarak algılar.

Hangi dosyalar özellikle kontrol edilmeli?

Yayına almadan önce yalnızca bilinen test dosyalarını değil, tüm geçici kalıntıları kontrol etmek gerekir. Aşağıdaki örnekler pratik bir kontrol listesi olarak kullanılabilir:

• phpinfo veya sunucu bilgisi gösteren dosyalar
• Veritabanı, SMTP, ödeme veya API bağlantı testleri
• Eski yedekler: .bak, .old, .zip, .tar.gz uzantılı dosyalar
• Geçici yükleme, log ve debug dizinleri
• Git, SVN veya IDE klasörlerinin web kök dizininde kalması
• Kurulum sihirbazları ve demo içerikler

Bu kontrol sadece yazılım ekibinin sorumluluğu gibi düşünülmemelidir. Yayın süreci, alan adı, DNS, SSL ve hosting yönetimiyle birlikte ele alınmalıdır; çünkü hatalı dizin izinleri veya yanlış belge kök dizini seçimi, güvenli yazılmış bir uygulamayı bile açık hale getirebilir.

Canlıya çıkmadan önce nasıl önlem alınır?

Dağıtım sürecini manuel kopyalamaya bırakmayın

FTP ile klasör sürükleyip bırakmak pratik görünse de test dosyalarının canlıya taşınmasına sık neden olur. Bunun yerine sürüm kontrolü, dağıtım listesi ve hariç tutma kuralları kullanılmalıdır. Canlı ortama yalnızca gerekli dosyaların gittiğinden emin olun.

Web kök dizinini sade tutun

Uygulamanın herkese açık olması gereken bölümü ile yapılandırma, log, yedek ve kaynak dosyaları aynı yerde tutulmamalıdır. Mümkünse yalnızca public veya benzeri bir dizin dış dünyaya açılmalı; diğer dosyalar web erişiminin dışında kalmalıdır.

Hata gösterimini kapatın, loglamayı içeride tutun

Canlı ortamda kullanıcıya ayrıntılı hata gösterilmemeli, hatalar güvenli bir log dosyasına yazılmalıdır. Log dosyaları da tarayıcıdan erişilebilir olmamalıdır. Aksi halde sorunu çözmek için tutulan kayıtlar, yeni bir bilgi sızıntısına dönüşebilir.

Unutulan dosyalar tespit edilirse ne yapılmalı?

İlk adım dosyayı sadece silmek değildir. Önce dosyanın ne kadar süredir erişilebilir olduğunu, erişim loglarında olağan dışı istek olup olmadığını ve dosyada hangi bilgilerin yer aldığını kontrol edin. İçinde parola, API anahtarı veya bağlantı bilgisi varsa bunları değiştirmeden dosyayı silmek yeterli olmaz.

Ardından ilgili anahtarları yenileyin, veritabanı kullanıcı yetkilerini daraltın, dosya izinlerini gözden geçirin ve benzer isimli dosyalar için tüm dizinleri tarayın. Kurumsal yapılarda bu işlem bir olay kaydıyla takip edilmeli; aynı hatanın tekrar etmemesi için canlıya çıkış kontrol listesine eklenmelidir.

Operasyonel kontrol listesi

Yayından önce şu kısa kontrol, birçok riski erken aşamada azaltır: test dosyalarını ara, yedek arşivleri kaldır, hata gösterimini kapat, dizin listelemeyi devre dışı bırak, gereksiz kurulum dosyalarını sil, erişim loglarını incele ve kritik bilgileri ortam değişkenleriyle yönetin. Paylaşımlı sunucu kullanılıyorsa panelde belge kök dizini, PHP sürümü ve dosya izinleri ayrıca doğrulanmalıdır.

Bu yaklaşım, yalnızca teknik bir temizlik değil, sürdürülebilir güvenlik alışkanlığıdır. Canlı sunucuda neyin bulunmaması gerektiğini netleştiren ekipler, yayın sonrası acil müdahale ihtiyacını azaltır ve kullanıcı verilerinin korunmasını daha kontrollü hale getirir.