Tüm rehberler
Kritik önem derecesiYapılandırma Hataları

Açıkta kalan veritabanı yedekleri: /backup.sql erişilebilir olduğunda ne olur

Veritabanı yedekleri — .sql dosyaları, sıkıştırılmış dump'lar, veritabanının zip arşivleri — bazen doğrudan web üzerinden erişilebilen bir dizinde oluşturulur ve orada unutulur. /backup.sql veya /dump.sql adresine yapılan tek bir başarılı istek, uygulama mantığına hiç dokunmadan saldırgana her tablonun her satırını teslim eder.

Nedir

Yedekleme script'leri, hosting kontrol panelleri ve manuel export araçları dump dosyalarını genellikle tahmin edilebilir adlarla yazar: backup.sql, dump.sql, database.sql, db.sql.gz, backup.zip. Bunlar web root'un içine düştüğünde ve sunucu onları açıkça engellemediğinde, sıradan indirilebilir dosyalara dönüşür. Saldırganlar, erişebildikleri her host'a karşı bu yaygın adlardan onlarcasını isteyen otomatik taramalar çalıştırır.

AppSafe en yaygın yolları — /backup.sql, /dump.sql, /database.sql, /db.sql.gz ve diğerlerini — kontrol eder ve içeriği SQL dump'ına veya arşive benzeyen bir 200 yanıtı döndüren her birini işaretler. Kontrol hem düz metin SQL'i hem de sıkıştırılmış formatları yakalar.

Neden önemli

Bir SQL dump'ı, alındığı andaki her tablonun her satırını içerir: kullanıcı hesapları, parola hash'leri, e-posta adresleri, kişisel veriler, oturum token'ları, ödeme geçmişi ve dahili uygulama durumu. Bir dump'ı indirmek, uygulama log'larında hiçbir iz bırakmayan tek bir HTTP isteğidir — web sunucusu onu herhangi bir statik dosya gibi sunar.

Sızan bir API key'inin aksine, sızan bir veritabanını rotate edemezsin. Biri kullanıcı tablonun bir kopyasını ele geçirdiğinde, bu kullanıcılar için ihlal kalıcıdır. Dump'ın içeriğine bağlı olarak GDPR, CCPA veya HIPAA kapsamında zorunlu ihlal bildirimleriyle ve etkilenen her kullanıcıyı bilgilendirmenin operasyonel maliyetiyle karşı karşıya kalabilirsin.

Nasıl düzeltilir

Yedekleri web root dışına taşı

Doğru çözüm, yedek dosyalarını web sunucusunun erişemeyeceği bir dizine yazmaktır — /var/www/ altındaki bir alt dizin değil, /var/backups/ gibi bir yol veya özel ACL'lere sahip bir object storage bucket'ı. Tüm cron job'larını ve yedekleme script'lerini gözden geçir ve hedef yolu güncelle.

Yaygın yedek uzantılarını nginx'te engelle

Derinlemesine savunma önlemi olarak, dosyalar nerede saklanırsa saklansın SQL dosyalarına ve yaygın arşiv uzantılarına yönelik istekleri sunucu seviyesinde reddet.

location ~* \.(sql|sql\.gz|bak|dump|tar|tar\.gz|tar\.bz2|zip)$ {
  deny all;
  return 404;
}
Web root'ta zaten bulunan dump dosyalarını sil

Açıkta kalan bir dosya bulursan hemen sil. Ardından oraya nasıl geldiğini incele — dosyayı oraya koyan script'i veya süreci düzelt ki bir sonraki zamanlanmış çalıştırmada yeniden ortaya çıkmasın.

Yolların 404 döndürdüğünü doğrula

Temizlikten sonra yaygın yolların engellendiğini doğrula.

for path in /backup.sql /dump.sql /database.sql /db.sql.gz; do
  code=$(curl -so /dev/null -w "%{http_code}" "https://yourdomain.com$path")
  echo "$path → $code"
done
# Every line must print 404

SSS

Bir saldırgan sitemde /backup.sql'i denemesi gerektiğini nereden bilir?

Özellikle seni hedef almazlar. Otomatik tarayıcılar, milyonlarca host'a karşı sürekli olarak onlarca yaygın yedek adını ister. Var olan bir dosya 200 döndürür ve sen bakman gerektiğini fark etmeden indirilir.

Dosya yalnızca bir saat orada kaldı. Zarar oluştu mu?

Muhtemelen. Otomatik taramalar günün her saati çalışır ve dosyalar genellikle ortaya çıktıktan birkaç dakika sonra bulunur. Erişim log'ların varsa yolun istenip istenmediğini kontrol et — istendiyse bunu doğrulanmış bir ihlal olarak ele al.

Dosyayı taşımak yerine parolayla koruyabilir miyim?

Tek bir dosyada basic auth kırılgandır ve yanlış yapılandırılması kolaydır. Doğru yanıt, dosyayı web üzerinden erişilebilen her konumdan tamamen kaldırmaktır. Yedekler, HTTP sunucusunun erişemeyeceği bir yerde durmalıdır.

Uygulaman etkileniyor mu?

AppSafe, bunu ve onlarca başka sorunu tek bir ücretsiz taramada kontrol eder.

Uygulamamı ücretsiz tara

Blogdan

PHP2Shell aktif olarak istismar ediliyor: uygulamanın açıkta olup olmadığını nasıl kontrol edersin

PHP'nin kendisindeki iki kritik hata, birkaç gün içinde "yama yayınlandı"dan "aktif olarak istismar ediliyor"a geçti. Barındırdığın herhangi bir şeyin etkilenen bir sürüm çalıştırıp çalıştırmadığını nasıl anlarsın ve bugün ne yapmalısın.

İlgili rehberler

Açık dizin indeksleri: dosya sunucun her şeyi listelediğinde

İçeriğini listeleyen bir dosya sunucusu, saldırganlara bedava bir envanter sunar.

.env dosyalarının açığa çıkması: saldırganlar secret'larını nasıl bulur

Erişilebilir tek bir .env, tüm stack'ini teslim edebilir.

Supabase Row Level Security (RLS): tablolarını kilitle

Anon key'in herkese açık. Onunla verilerin arasındaki tek şey RLS.

Açıkta kalan .git dizini: göz önünde saklanan kaynak kodu sızıntısı

Erişilebilir bir /.git, tüm kod tabanını ve commit geçmişini teslim eder.