Hassas Dosya İfşası (.git, .env, Yedek Dosyalar)

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Güvenlik Yanlış Yapılandırması / Bilgi İfşası
Tipik Önem Derecesi Kritik
OWASP A05:2021 – Güvenlik Yanlış Yapılandırması
CWE CWE-538: Hassas Bilginin Dışarıdan Erişilebilir Dosyaya/Dizine Eklenmesi; CWE-548: Dizin Listeleme Yoluyla Bilgi İfşası
Diğer adları Hassas Dosya İfşası, Kimlik Bilgisi Sızıntısı, Kaynak Kod Sızıntısı, Yedek Dosya Açığı
Etkilenen sistemler Web sunucuları (Apache, Nginx, IIS, Caddy), Git ile dağıtılan uygulamalar, .env tabanlı yapılandırma kullanan her ortam, CMS platformları (WordPress, Laravel, Django vb.)
Yaygın hedef dosyalar .git/, .env, .env.local, .env.production, web.config, .htaccess, *.bak, *.old, *.sql, *.tar.gz, *.zip, database.yml, config.php

Genel Bakış

Hassas dosya ifşası; sürüm kontrolü meta verileri, ortam değişkenleri, kriptografik anahtarlar veya veritabanı dökümleri gibi gizli bilgiler içeren dosya ya da dizinlerin, kimlik doğrulaması veya erişim denetimi olmaksızın HTTP(S) üzerinden erişilebilir olmasıyla ortaya çıkar. Bu, uygulama katmanı değil; sunucu tarafı bir yanlış yapılandırma sorunudur: söz konusu veriler hiçbir zaman herkese açık sunulması amaçlanmamıştır, ancak web sunucusu erişimi kısıtlamamaktadır.

En yaygın istismar edilen üç dosya sınıfı şunlardır:

  • .git dizinleri: Bir Git deposu çalışma dizini kopyalanarak web köküne dağıtıldığında, tam commit geçmişini, nesne veritabanını, yapılandırmayı ve uzak URL'leri içeren .git/ klasörü herkese açık hâle gelir. git-dumper gibi araçlar, açık bir .git/ dizininden tüm kaynak ağacını yeniden oluşturabilir.
  • .env dosyaları: Laravel, Symfony, Django ve Node.js gibi çerçeveler tarafından popülerleştirilen Onikifaktörlü Uygulama metodolojisinde .env dosyaları; veritabanı kimlik bilgileri, API anahtarları, OAuth token'ları ve şifreleme anahtarları gibi çalışma zamanı sırlarını düz metin anahtar-değer çiftleri olarak depolar. /.env adresine yapılacak tek bir HTTP GET isteği, uygulamadaki tüm sırları ifşa edebilir.
  • Yedek ve arşiv dosyaları: Geliştiriciler ve sistem yöneticileri zaman zaman yapılandırma dosyalarının veya tüm web kökünün yedek kopyalarını diskte bırakır (örn. config.php.bak, site.tar.gz, dump.sql). Web sunucuları bu dosyaları herhangi bir statik varlık gibi sunar ve saldırganlara kimlik bilgilerini veya tam veritabanı içeriklerini doğrudan indirme imkânı tanır.

Sensagraph, sürekli tarama sürecinde yüzlerce bilinen hassas dosya yolunu otomatik olarak denetler.

Nasıl çalışır?

Saldırganlar, hedef bir kaynakta bilinen yolları listelemek için otomatik tarayıcılar ve manuel sorgulama kullanır. HTTP yanıt kodu ve yanıt gövdesi, dosyanın mevcut ve erişilebilir olup olmadığını belirler:

  • Boş olmayan bir gövdeyle dönen 200 OK yanıtı, dosyanın herkese açık erişilebilir olduğunu doğrular.
  • 403 Forbidden yanıtı, yolun var olduğunu ancak kısıtlandığını doğrular; dizin yapısını ortaya çıkardığı için bu da bir bilgi sızıntısıdır.
  • 404 Not Found yanıtı, kaynağın mevcut olmadığını veya erişilemez olduğunu gösteren istenen temel durumdur.

.git/ yeniden yapılandırma saldırısı

Dizin listesi etkin olmasa bile /.git/HEAD ve /.git/config adreslerine erişebilen bir saldırgan, depo yapısını çıkarabilir ve Git nesnelerini (/.git/objects/<sha>) yinelemeli olarak indirebilir. Otomatik araçlar çalışma ağacını yerel olarak yeniden oluşturarak gömülü sırları, iç yorumları ve dosya yollarını içeren tam kaynak kodu ortaya çıkarır. /.git/objects/pack/ dizinindeki PACK dosyaları tüm depoyu tek bir indirilebilir arşive sıkıştırabilir.

.env dosyası ifşası

Çerçeveler ve dağıtım betikleri genellikle .env dosyasını uygulama köküne yerleştirir; bu konum web köküyle çakışabilir veya bir üst dizinde olabilir. Yanlış yapılandırılmış bir belge kökü ya da eksik bir reddetme kuralı dosyayı ifşa eder. Yaygın girdiler şunlardır:

  • DB_PASSWORD, DB_HOST, DATABASE_URL — doğrudan veritabanı erişimi
  • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY — bulut altyapısı ele geçirme
  • APP_KEY, SECRET_KEY — oturum sahteciliği veya şifrelenmiş verilerin çözülmesini mümkün kılan şifreleme anahtarı ifşası
  • STRIPE_SECRET_KEY, SENDGRID_API_KEY — üçüncü taraf hizmet kötüye kullanımı

Yedek dosya ifşası

Yedek dosyalar genellikle metin editörleri (örn. index.php~, wp-config.php.bak), cPanel yedekleme araçları veya manuel arşivleme tarafından oluşturulur. Yolları tahmin edilebilir ve bir sözcük listesinden kolayca bulunabilir ya da listelenebilir. Statik dosyalar olduklarından uygulama katmanı mantığı indirmelerini engelleyemez.

İş etkisi

Hassas dosya ifşasının sonuçları kimlik bilgisi hırsızlığından tam sistem ele geçirmeye kadar uzanır:

  • Tam kaynak kod ifşası: Tescilli iş mantığını, giderilmemiş güvenlik açıklarını ve iç mimariyi saldırganlara açar.
  • Kimlik bilgisi ve sır sızıntısı: .env veya .git geçmişinden çıkarılan veritabanı parolaları, API anahtarları ve özel anahtarlar; yanal hareket, veri sızdırma ve altyapı ele geçirilmesini mümkün kılar.
  • Veritabanı ele geçirme: Açık SQL dökümlerinden saldırganlara kullanıcı kimlik bilgileri (düz metin veya özetlenmiş), kişisel veriler, ödeme bilgileri ve diğer düzenlenmiş bilgiler sağlanır; bu durum GDPR, PCI-DSS ve HIPAA kapsamında ihlal bildirimi yükümlülüklerini tetikler.
  • Bulut kaynaklarının kötüye kullanımı: Sızdırılan bulut sağlayıcı kimlik bilgileri (AWS, GCP, Azure) kripto madenciliği altyapısı kurmak, başka saldırılar başlatmak veya önemli mali yükler oluşturmak için kullanılabilir.
  • Yasal ve düzenleyici sorumluluk: Kişisel verilerin izinsiz ifşası, GDPR (Madde 33) kapsamında küresel yıllık cirosun %4'üne kadar para cezasıyla bildirilebilir bir olay teşkil eder.
  • İtibar kaybı: Kaynak kodu ve kimlik bilgisi sızıntıları sıklıkla arama motorları tarafından dizine alınır veya tehdit istihbaratı topluluklarında paylaşılarak ifşayı kamuoyuna mal eder.

Nasıl düzeltilir?

  1. .git/ dizinini hiçbir zaman web köküne dağıtmayın. Yalnızca derlenmiş uygulama yapılarını kopyalayan ve depo meta verilerini dışlayan bir CI/CD hattı veya dağıtım aracı (örn. dışlama seçenekli rsync, Deployer, Capistrano) kullanın. .git/ zaten açık durumdaysa web kökünden hemen kaldırın ve commit geçmişinde bulunan tüm sırları değiştirin.
  2. Web sunucusu düzeyinde hassas yollara erişimi engelleyin. Herhangi bir yanlışlıkla yapılan dağıtım zarar vermeden önce açık reddetme kuralları yapılandırın:
    • Nginx: location ~* /\.(git|env|htaccess|htpasswd|svn|DS_Store)(/|$) { deny all; return 404; }
    • Apache: <FilesMatch "\.(git|env|bak|old|sql|tar|gz|zip|log)$"> Require all denied </FilesMatch>
    • IIS: Bu yollara yapılan istekleri reddetmek için web.config dosyasına <requestFiltering> kuralları ekleyin.
  3. .env dosyalarını web kökünün dışında tutun. Yapılandırma dosyalarını belge kökünün bir veya daha fazla dizin seviyesi üzerinde depolayın (örn. web kökü /var/www/app/public/ iken /var/www/app/.env). Çerçeve yapılandırmasını doğru yolu gösterecek şekilde güncelleyin.
  4. Bir sır yönetim sistemi kullanın. Dosya tabanlı sırları özel bir sır yöneticisiyle (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) değiştirin. Sırları diskteki bir dosya aracılığıyla değil, işlem yöneticisi tarafından ayarlanan ortam değişkenleri aracılığıyla çalışma zamanında enjekte edin.
  5. Hassas dosya kalıplarını .gitignore'a ekleyin. .env, *.bak, *.sql, *.tar.gz, *.log ve diğer hassas kalıpların .gitignore dosyasında listelendiğinden ve commit edilmemiş olduğundan emin olun. Geçmişi denetlemek için git log --all -- <dosyaadı> komutunu kullanın.
  6. Açık olan tüm kimlik bilgilerini derhal değiştirin. Bir .env dosyası veya Git geçmişi ifşası onaylanırsa içerdiği her sırrı güvenliği ihlal edilmiş sayın: parolaları değiştirin, API anahtarlarını yeniden oluşturun, sertifikaları iptal edip yeniden düzenleyin ve yetkisiz kullanım için erişim günlüklerini denetleyin.
  7. Dizin listelemesini devre dışı bırakın. Dizin listesi dosyası olmayan dizinlerin dosya listesi yerine 403 döndürmesi için Options -Indexes (Apache) veya autoindex off (Nginx) ayarının genel olarak yapıldığından emin olun.
  8. Bir Web Uygulama Güvenlik Duvarı (WAF) kuralı uygulayın. Bilinen hassas yolları hedef alan istekleri engellemek için WAF kuralları ekleyin (/.git/, /.env, /.htaccess, yaygın yedek uzantıları). Bu, sunucu tarafı kontrollerine ek savunma derinliği sağlar.
  9. Düzenli dosya ifşası denetimleri gerçekleştirin. Dağıtımların neden olduğu gerilemeleri yakalamak için rutin güvenlik testlerinin (sızma testleri, otomatik tarama) bir parçası olarak hassas dosya yolu listesini dahil edin.

Kaynaklar

Sıkça sorulan sorular

https://alanadiniz.com/.git/HEAD adresine bir HTTP GET isteği gönderin. Sunucu, 'ref: refs/heads/main' gibi bir metin içeren 200 OK yanıtı dönüyorsa .git dizininiz herkese açık demektir ve erişim derhal kısıtlanmalıdır. 404 yanıtı, dizine erişilemediğini gösterir.

403 yanıtı, 200'den daha iyidir; ancak .git dizininin sunucuda var olduğunu doğrular. Web sunucusu yapılandırmasına bağlı olarak, dizin listesi reddedilse bile .git/ içindeki ayrı dosyalar doğrudan erişilebilir durumda olabilir. En güvenli sonuç 404 yanıtıdır; yolu tamamen engelleyerek veya .git/ dizinini web köküne hiç dağıtmayarak elde edilir.

Bu güvenlik açığı, .git dizininin HTTP üzerinden herkese açık sunulmasıyla ilgilidir. Ancak özel bir depoya commit edilmiş sırlar, çalışma dizini .git/ dahil şekilde herkese açık bir web sunucusuna dağıtılırsa açığa çıkabilir. İfşa, depo barındırma katmanında değil web sunucusu katmanında gerçekleşir.

Olayı onaylanmış kimlik bilgisi ele geçirilmesi olarak değerlendirin. Dosyada listelenen her sırrı derhal değiştirin: veritabanı parolaları, API anahtarları, şifreleme anahtarları, OAuth token'ları ve diğer tüm kimlik bilgileri. Dosyanın ilk dağıtıldığı tarihten itibaren uygulama ve altyapı erişim günlüklerini yetkisiz erişim için denetleyin. Geçerli veri koruma mevzuatının (örn. KVKK, GDPR Madde 33) gerektirdiği şekilde ilgili tarafları bilgilendirin.

Evet. Otomatik tarayıcılar, bilinen dosya adlarından türetilen tahmin edilebilir yedek dosya adlarını (örn. index.php.bak, wp-config.php.old, config.php~) rutin olarak tarar. Bu sözcük listeleri herkese açık ve yaygın kullanımdadır. Web kökünde bırakılan hassas bir ada ve yaygın bir yedek uzantısına sahip her dosya keşfedilebilir olarak değerlendirilmelidir.

Her ikisini de etkiler. WordPress, Joomla, Drupal ve Laravel tabanlı uygulamalar gibi CMS platformları, dosya yapıları ve yaygın dosya adları iyi bilinen hedefler olduğundan sıkça taranır. WordPress siteleri wp-config.php.bak için, Laravel uygulamaları ise .env için yaygın biçimde incelenir. Kullanılan temel teknolojiden bağımsız olarak dikkatsizce dağıtılan her web uygulaması etkilenebilir.