Hastanelerin arşiv odalarında saklanan hasta epikriz dosyaları, kan tahlilleri, psikiyatrik seans notları ve adli vaka tutanakları en yüksek gizlilik derecesine sahip mahrem belgelerdir. Kanun gereği bu evraklar kilitli çelik dolaplarda tutulur. Şimdi hastane arşiv memurunun, "Dosyaları diğer binaya taşıyacağım, servis aracı gelene kadar burada dursun" diyerek 50.000 hastanın tüm tıbbi geçmişini içeren yüzlerce klasörü hastanenin ana caddeye bakan açık kaldırımına yığdığını hayal edin. Üstüne de herkesin göreceği şekilde büyük bir karton koyup "Hastanemizin 2026 Yılı Tüm Hasta Kayıtları Yedeği" yazdığını düşünün. Caddeden geçen magazinciler, sigorta dolandırıcıları ve meraklı kalabalıklar klasörleri poşetlerine doldururken memur içeride çay içmektedir. Yaşanan şey bir hırsızlık değil; mahremiyetin kamusal alana bizzat yetkili eliyle saçılmasıdır.

Türkiye'deki web geliştiricilerinin ve sistem yöneticilerinin önemli bir kısmının mysqldump veya phpMyAdmin ile aldığı veritabanı yedeğini doğrudan public_html, www veya htdocs dizininin içine yedek.sql, dump.sql veya db_2026.sql adıyla kaydetmesi ve orada unutması, kaldırıma hasta dosyası yığmaktan farksızdır.

"Kimse Bu URL'yi Tahmin Edemez" Yanılgısı

Geliştirici sunucuya SSH veya cPanel Dosya Yöneticisi üzerinden bağlanır. Sitede büyük bir güncelleme yapacaktır:

# Geliştiricinin masumane komutu:
cd /var/www/vhosts/sirket.com/public_html
mysqldump -u root -p sirket_db > yedek.sql

Geliştirici kendi kendine düşünür: "Ben bunu buraya geçici koydum. 1 saat sonra sileceğim. Zaten sitemde bunun linki yok, Google nereden bilecek? Kimse sirket.com/yedek.sql yazmayı akıl edemez."

Bu düşünce zinciri, web güvenliği tarihindeki en büyük yanılsamalardan biridir. Çünkü internette gezen botlar linkleri tıklayarak ilerlemez; dizinleri sözlük saldırısıyla (dictionary brute-force) tarar ve arama motorlarının dizinleme robotlarını kullanır.

Google Dorking: İnternetin Açıkta Duran Röntgen Cihazı

Arama motorları (Google, Bing, Yandex, DuckDuckGo) internetteki tüm web sunucularını durmaksızın tarar. Eğer web sunucunuzda dizin listeleme (Directory Listing / Options +Indexes) açıksa veya dosya adı başka bir yerde geçtiyse; arama motoru bu dosyayı indeksine katar.

Saldırganlar ise Google'ın gelişmiş arama operatörlerini (Google Dorks) kullanarak saniyeler içinde binlerce açıkta duran veritabanı yedeğini ekrana döker:

# Saldırganın Google'a yazdığı basit bir sorgu:
filetype:sql inurl:backup OR inurl:dump OR inurl:yedek "INSERT INTO"
filetype:sql "wp_users" "user_pass"
site:*.com.tr filetype:sql intext:password

Google bu sorguya karşılık, Türkiye'deki e-ticaret sitelerinin, hukuk bürolarının, hastanelerin ve belediyelerin web sunucularında açıkta unutulmuş binlerce .sql dosyasını doğrudan tıklanabilir indirme bağlantısı olarak listeler!

                  ┌──────────────────────┐
                  │  Saldırgan / Dorker  │
                  └──────────┬───────────┘
                             │ Google: filetype:sql inurl:yedek
                             ▼
                    [GOOGLE ARAMA MOTORU]
                             │
     ┌───────────────────────┼───────────────────────┐
     ▼                       ▼                       ▼
https://firmaA.com/yedek.sql https://klinikB.com/db.sql https://ajansC.com/2026.sql
     │                       │                       │
     ▼ (Tek Tıkla İndir)     ▼ (Tek Tıkla İndir)     ▼ (Tek Tıkla İndir)
[Tüm Müşteri Listesi]   [Hasta Epikrizleri]     [Kullanıcı Şifreleri]
[Banka Bilgileri]       [Kredi Kartı Logları]   [Admin Token'ları]

Saldırganın tek yapması gereken "İndir" butonuna basmaktır. Tek bir güvenlik duvarını aşmamış, tek bir exploit çalıştırmamış, tek bir şifre kırmamıştır. Kapıyı ardına kadar bizzat geliştirici açmıştır.

Sadece Google Değil: Otomatik Fuzzing ve Wordlist Botları

Eğer dosyanız Google tarafından indekslenmemiş olsa bile güvende değilsinizdir.

Saldırganlar her gün milyonlarca domaini otomatik Fuzzing araçlarıyla (FFUF, Dirsearch, Gobuster) tarar. Bu araçların elinde en yaygın kullanılan dosya isimlerinin bulunduğu devasa sözlükler vardır:

  • yedek.sql, backup.sql, data.sql, database.sql
  • db.sql, dump.sql, sql.sql, 1.sql
  • sirket.sql, sirket_yedek.sql, 2026.sql, eski.sql
  • backup.tar.gz, site.zip, public_html.rar

Web sunucunuza saniyede 100 istek atarak bu isimleri denerler. Biri 200 OK yanıtı verdiği an dosya otomatik olarak saldırganın sunucusuna indirilir. İndirme bittiğinde içindeki e-posta ve şifre hash'leri otomatik olarak ayrıştırılıp Dark Web forumlarına (RaidForums / BreachForums) satışa konur.

İfşa Olan Bir .sql Dosyasının Anatomisi

Bir veritabanı yedeğinin indirilmesi, şirketin dijital kıyafetlerinin tamamen çıkarılması demektir. Metin editörüyle açılan o .sql dosyasının içinde şunlar yer alır:

  1. Kullanıcı Şifreleri (Hash'ler):
    INSERT INTO users VALUES (1, 'admin', '$2y$10$e8...', '[email protected]'). Hashcat veya John the Ripper ile zayıf şifreler dakikalar içinde kırılır.
  2. Kişisel Veriler (KVKK İhlali):
    Müşterilerin adları, soyadları, T.C. kimlik numaraları, ev adresleri, cep telefonları, sipariş geçmişleri.
  3. Gizli Uygulama Ayarları:
    SMTP mail şifreleri, SMS API anahtarları, sanal POS mağaza anahtarları ve gizli tuz (salt) değerleri.

Ertesi gün şirketin tüm müşterilerine "Firma veritabanı hacklendi, fidye ödenmezse verileriniz yayınlanacak" mesajları gitmeye başlar.

Klinik Tedavi ve Cerrahi Koruma Protokolü

Web sunucusunda veri sızıntılarını engellemek üç basit ama tavizsiz kurala bağlıdır:

1. Web Kök Dizinini Asla Depolama Alanı Olarak Kullanmayın!

Veritabanı yedekleri, loglar, arşivler veya geçici dosyalar ASLA public_html veya www dizini altında tutulamaz!
Yedek alınacaksa, web sunucusunun HTTP üzerinden erişemeyeceği bir üst dizinde (/home/kullanici/backups/) tutulmalıdır:

# Hatalı:
mysqldump -u user -p db > /var/www/html/yedek.sql
 
# Doğru: Web kökünün tamamen dışında, izole dizin!
mysqldump -u user -p db > /var/backups/db_$(date +%F).sql
chmod 600 /var/backups/db_*.sql

2. Web Sunucusunda Hassas Uzantıları Kesin Olarak Yasaklayın!

Geliştiricilerin insan olduğunu ve hata yapabileceğini kabul edin. Mimariniz, geliştirici yanlış yere dosya koysa bile o dosyanın web'den indirilmesine izin vermemelidir!

Nginx İçin Savunma Kalkanı:
# .sql, .bak, .zip, .tar, .env gibi tehlikeli uzantıları anında 403 ile engelle!
location ~* \.(sql|bak|backup|config|env|log|tar|gz|zip|rar|git)$ {
    deny all;
    return 404;
}
Apache (.htaccess) İçin Savunma Kalkanı:
<FilesMatch "\.(sql|bak|backup|env|log|zip|tar\.gz)$">
    Order allow,deny
    Deny from all
</FilesMatch>
 
# Dizin listelemeyi mutlaka kapatın!
Options -Indexes

Bu iki kuralı eklediğinizde, geliştirici yanlışlıkla public_html/yedek.sql oluştursa bile dışarıdan gelen istek 404 Not Found alır; dosya indirilemez!

3. Düzenli Olarak Kendi Dizinlerinizi Denetleyin

Sunucunuzda unutulmuş tehlikeli dosyaları tespit etmek için haftalık bir tarama betiği çalıştırın:

find /var/www/ -type f \( -name "*.sql" -o -name "*.tar.gz" -o -name "*.zip" -o -name "*.env" \) -ls

Ekrana bir satır bile düşerse derhal o dosyayı web kökünün dışına taşıyın.

Sonuç

Hasta dosyalarını hastane bahçesindeki kaldırıma bırakıp "Ama kimsenin alacağını düşünmemiştim" diyen bir idareci mahkemede nasıl ceza almaktan kurtulamazsa; web kök dizinine .sql bırakıp hacklenen bir şirket de KVKK cezalarından ve itibar kaybından kurtulamaz.

Web dizini bir dosya deposu değil, yalnızca dünyaya sunulması gereken statik ve dinamik kodların vitrinidir. Yedeklerinizi vitrinde değil, kilitli kasalarda tutun; mimarinizi dork avcılarının açık büfesi haline getirmeyin.