Dizin Listeleme ve Hassas Dosya İfşasını Nasıl Önlersiniz

Düzeltmeleri uygulamadan önce bu güvenlik açıklarının pratikte nasıl göründüğünü anlamak önemlidir. Dizin listeleme, bir dizinde index dosyası (örn. index.html) bulunmadığında web sunucusunun dizin içeriğini taranabilir bir HTML sayfası olarak görüntülemesiyle oluşur. Hassas dosya ifşası ise .env, config.php, veritabanı dökümleri veya .git klasörleri gibi dosyalara doğrudan URL ile erişilebildiğinde meydana gelir. Her iki sorun da saldırganlara kimlik bilgileri, kaynak kodu, iç yollar ve daha ileri saldırıları hızlandıran diğer bilgileri sağlar.

• Canlı sitenizde / ile biten ve dizin listeleme sayfası döndüren URL'leri arayın (sayfa başlığında "Index of /" ifadesini kontrol edin).
• Yaygın hassas yollara doğrudan erişmeyi deneyin: /.env, /config.php, /wp-config.php, /.git/config, /backup.zip, /database.sql.
• Alt alan adlarını ve hazırlık (staging) ortamlarını kontrol edin — bunlar çoğunlukla gözden kaçar ve yanlış yapılandırılmış olarak bırakılır.
• Tüm web varlığınızda açık dizinleri ve hassas dosyaları tespit etmek için Sensagraph'ın otomatik taramalarından yararlanın.

Tüm büyük web sunucularının dizin listelemeyi kapatmak için basit bir yolu vardır. Altyapınıza uyan yapılandırmayı uygulayın ve devam etmeden önce değişikliğin aktif olduğunu doğrulayın.

• Apache: httpd.conf, sanal ana bilgisayar bloğu veya .htaccess dosyanıza şunu ekleyin ya da doğrulayın: Options -Indexes. Bu tek direktif Apache'nin dizin listesi oluşturma yeteneğini kaldırır.
• Apache (.htaccess): Ana yapılandırmayı düzenleyemiyorsanız, taranmaması gereken her dizine şunu içeren bir .htaccess dosyası yerleştirin: Options -Indexes.
• Nginx: İlgili server veya location bloğunda autoindex'in devre dışı olduğundan emin olun: autoindex off;. Bu varsayılan değerdir ancak istemeden açılmadığını teyit edin.
• IIS: IIS Manager'da sitenizi seçin, "Directory Browsing" bölümünü açın ve Eylemler panelinde "Disable" düğmesine tıklayın. Alternatif olarak web.config dosyasına <directoryBrowse enabled="false" /> ekleyin.
• Caddy: file_server browse direktifini kullanmayın; yalnızca file_server kullanın; bu dizinleri listelemeden dosya sunar.
• Değişiklikleri yaptıktan sonra, tarayıcınızda boş bir dizine giderek test edin — dosya listesi değil, 403 Forbidden veya 404 Not Found almalısınız.

Dizin listelemeyi devre dışı bırakmak gereklidir ancak yeterli değildir. Saldırganlar, dosya adını biliyorlarsa veya tahmin edebiliyorlarsa hassas dosyalara doğrudan istekte bulunabilir. Bilinen tehlikeli dosya türleri ve dizinlere erişimi açıkça reddetmeniz gerekir.

• Apache (.htaccess veya httpd.conf): Tehlikeli dosya uzantıları ve gizli dosyalara erişimi reddetmek için kurallar ekleyin:
  <FilesMatch "(\.env|\.git|\.htaccess|\.htpasswd|\.DS_Store|composer\.json|composer\.lock|package\.json|yarn\.lock|\.bak|\.sql|\.log|\.config)$">
Require all denied
</FilesMatch>
• Nginx: Hassas dosyalara erişimi reddetmek için location blokları ekleyin:
  location ~* /\.(?!well-known) { deny all; }
location ~* \.(env|git|bak|sql|log|config|json|lock)$ { deny all; }
• .git dizinini tamamen engelleyin — açık bir .git klasörü tam kaynak kodu yeniden oluşturulmasına olanak tanır.
• composer.json, composer.lock, package.json ve yarn.lock dosyalarına erişimi engelleyin — bunlar bağımlılık ağacınızı ve bilinen savunmasız sürümlerinizi ortaya koyar.
• Yaygın yedek dosya uzantılarını engelleyin: .bak, .old, .orig, .tmp, .swp, .~.
• .log dosyalarını engelleyin — uygulama günlükleri sıklıkla yığın izleri, kullanıcı verileri ve dahili IP adresleri içerir.
• /vendor dizini web kökünizdeyse kısıtlayın (mümkünse web kökünün üzerine taşıyın).

Yapılandırma ve gizli dosyalar için en sağlam koruma, bunları web sunucusunun sunabileceği her konumdan kaldırmaktır. Web kökünün dışındaki dosyalar, sunucu yapılandırma hatalarından bağımsız olarak HTTP isteklerine yapısal olarak erişilemezdir.

• .env dosyalarını, veritabanı yapılandırmasını ve API anahtarlarını web kökünün bir üst dizininde saklayın (örn. /var/www/html/ veya /public_html/ dizininin üstünde).
• Uygulama kodunuzda bu dosyalara sabit kodlanmış mutlak yollar yerine göreli yollar veya ortam değişkenleri aracılığıyla başvurun.
• Composer'ın vendor/ dizinini web kökünün üstüne taşıyın ve otomatik yükleyici yolunuzu buna göre güncelleyin.
• Kullanıcı tarafından yüklenen dosyaları web kökünün dışındaki bir dizinde saklayın ve bunları kimlik doğrulama ile dosya türü doğrulaması uygulayan bir kontrolör komut dosyası aracılığıyla sunun.
• Derleme yapıtlarının, test verilerinin ve başlangıç verisi dosyalarının hiçbir zaman genel web köküne dağıtılmadığından emin olmak için dağıtım sürecinizi gözden geçirin.

Web sunucusu kuralları erişimi engellese bile, aşırı izinli dosya sistemi izinleri dosyaları aynı sunucudaki diğer süreçlere veya kullanıcılara açabilir. İşletim sistemi düzeyinde en az ayrıcalık ilkesini uygulayın.

• Web sunucusu süreçleri (örn. www-data, nginx, apache), açıkça gerekmedikçe (örn. yükleme dizini) uygulama dosyalarına yalnızca okuma erişimine sahip olmalıdır — asla yazma erişimi vermemelisiniz.
• Yapılandırma dosyalarını 600 (yalnızca sahip okuma/yazma) veya 640 (sahip okuma/yazma, grup okuma) moduna getirin; böylece web sunucusu süreci bunlara yazamaz.
• Dizinleri uygun şekilde 750 veya 755 moduna ayarlayın; asla 777 kullanmayın.
• Dünya tarafından yazılabilir dosyaları belirlemek ve hemen düzeltmek için find /var/www -perm -o+w (veya web kök yolunuz) komutunu çalıştırın.
• .env ve diğer gizli dosyaların dağıtım kullanıcısına ait olduğundan ve web sunucusu süreci tarafından okunabilir olmadığından emin olun — mümkün olan durumlarda dosya tabanlı sırlar yerine bir sırlar yöneticisi veya ortam enjeksiyonu kullanın.
• Paylaşımlı barındırma ortamlarında, yanlış yapılandırılmış open_basedir veya suEXEC ayarları aracılığıyla diğer hesapların dosyalarınızı okuyamadığını doğrulayın.

Geliştirici kolaylık dosyaları, geçici test sayfaları ve unutulmuş yedekler, hassas dosya ifşasının kalıcı bir kaynağıdır. Her dağıtımın parçası olarak temizleme alışkanlığı edinin.

• Tüm phpinfo() sayfalarını, test komut dosyalarını (örn. test.php, info.php) ve ilk kurulumdan sonra kurulum sihirbazlarını kaldırın.
• Veritabanı döküm dosyalarını (*.sql, *.dump) kullandıktan hemen sonra web kökünden silin — bunları sunucu dışında güvenli bir şekilde saklayın.
• Kurulum tamamlandıktan sonra CMS kurulum dizinlerini kaldırın (örn. WordPress'in /wp-admin/install.php dosyası, Joomla'nın /installation/ dizini).
• Yaygın hassas dosya adlarını tarayıp üretime dağıtılmasını engelleyen bir ön dağıtım kontrolü veya CI/CD pipeline adımı ekleyin.
• Sunucuda yerinde düzenleme sırasında Vim, Emacs veya diğer editörlerin bıraktığı editör takas dosyaları (.swp, ~dosyaadı) için web kökünüzü denetleyin.
• Kazara işleme yapılmasını önlemek için .git/, *.env, *.bak, *.sql ve *.log ifadelerini .gitignore dosyanıza ekleyin — ancak .gitignore'un zaten depoda bulunan dosyaları korumadığını unutmayın.

403 Forbidden ve 404 Not Found için varsayılan sunucu hata sayfaları çoğunlukla web sunucu adını, sürümünü ve işletim sistemini ortaya koyar. Bunları, doğru HTTP durum kodunu döndüren ancak sunucu ayrıntılarını paylaşmayan özel sayfalarla değiştirin.

• Apache: Yapılandırmanıza şunları ekleyin: ErrorDocument 403 /errors/403.html ve ErrorDocument 404 /errors/404.html.
• Nginx: Server bloğunuzda şunları kullanın: error_page 403 /errors/403.html; ve error_page 404 /errors/404.html;.
• Özel hata sayfalarınızın kendilerinin iç yolları, yığın izlerini veya uygulama sürüm numaralarını ifşa etmediğinden emin olun.
• Server HTTP yanıt başlığını kaldırın veya genel bir değerle değiştirin: Apache'de ServerTokens Prod ve ServerSignature Off kullanın; Nginx'te server_tokens off; kullanın.
• X-Powered-By başlıklarını devre dışı bırakın: PHP'de php.ini dosyasında expose_php = Off ayarlayın; Express.js'de app.disable('x-powered-by') çağrısını yapın.

Tek seferlik sertleştirme yeterli değildir. Yeni dağıtımlar, CMS güncellemeleri ve geliştirici hataları herhangi bir zamanda açık dosyaları yeniden ortaya çıkarabilir. Güvenlik iş akışınıza sürekli doğrulamayı dahil edin.

• Web uygulamanızın yeni açıklanan dizinlerini, yedek dosyalarını ve yapılandırma dosyalarını tespit etmek için düzenli otomatik taramalar planlayın — Sensagraph bu kontrolleri sürekli olarak gerçekleştirir ve sorunlar ortaya çıktığında sizi uyarır.
• Hassas dosya kalıplarının üretime ulaşmadan önce işaretlenmesi için CI/CD pipeline'ınıza bir güvenlik tarama adımı entegre edin.
• Hassas yollara yapılan istekler için (örn. /.env, /.git/config, /backup.zip) web sunucusu erişim günlüklerini periyodik olarak gözden geçirin — tekrarlanan girişimler aktif keşif faaliyetine işaret eder.
• Her büyük dağıtım veya altyapı değişikliğinin ardından dizin listeleme ve hassas dosya kontrollerini manuel olarak yeniden çalıştırın.
• CMS'iniz, framework'ünüz ve sunucu yazılımınız için güvenlik danışmalarına abone olun — yamalar bazen varsayılan yapılandırmaları değiştirir.
• Dahili sızma testi veya hata ödülü kapsamınıza dizin listeleme ve hassas dosya kontrollerini dahil edin.