SQL Injection’dan Nasıl Korunursunuz?

SQL Injection Nedir? Veritabanınızı Nasıl Korursunuz? sorusunun cevabı aslında şu cümlede gizli: Kullanıcıdan gelen veriye körü körüne güvenirseniz, veritabanınız bir gün mutlaka patlar. İster WordPress kullanın, ister kendi yazdığınız özel bir PHP uygulaması olsun; arada bir yerde veritabanına giden dinamik bir SQL sorgusu varsa, orada potansiyel bir açık da vardır. İşin can sıkıcı tarafı, bu saldırılar çoğu zaman yüksek trafik, pahalı sunucu, hızlı disk falan dinlemez; tek bir zayıf sorgu bütün sistemi dizüstü çökertebilir.

Şöyle düşünün: Site ziyaretçisi gibi görünen saldırgan, aslında form alanlarına SQL komutu yazıp, uygulamanıza “bunu veritabanında çalıştır” diye emir veriyor. Siz de farkında olmadan “peki” diyorsanız, olay bitmiştir. Bu yazıda teknik detayı boğmadan, ama yüzeysel de kalmadan, gerçekten günlük hayatta işinize yarayacak SQL Injection mantığını ve veritabanınızı nasıl koruyacağınızı konuşacağız. Hem junior geliştiriciye, hem de geceleri prod üzerinde direkt sorgu çalıştıranlara hitap edecek bir dille.

SQL Injection Nedir? Veritabanınızı Nasıl Korursunuz? Hakkında Bilmeniz Gerekenler

Aslında durum tam olarak şöyle: SQL Injection, uygulamanın “kullanıcı girişi” ile “SQL komutu” arasındaki sınırı ayırt edememesi. Yani veriyi veri olarak değil, komut gibi işlemesi. Bu yüzden saldırgan, normalde sadece “kullanıcı adı” yazması beklenen yere, ek SQL parçaları ekleyip sorguyu manipüle ediyor. Örneğin klasik örnek: ' OR 1=1 --. Basit ama çoğu eski uygulamada hala çalışıyor.

Bu teknoloji ya da daha doğrusu bu güvenlik tartışması niye var? Çünkü dinamik web siteleri, kullanıcıya özel içerik göstermek için veritabanı ile konuşmak zorunda. Login işlemi, ürün listeleme, sipariş geçmişi, admin paneli… Bunların hepsi SQL ile dönen veriye güveniyor. Araya doğru düzgün bir güvenlik katmanı konmadığında, saldırganlar bu kanalı tersine kullanıp veritabanına istedikleri komutu çalıştırabiliyor. Sonuç: Tüm kullanıcı verileri çalınabiliyor, tablolar silinebiliyor, bazı durumlarda sunucuya erişim için köprü bile kurulabiliyor.

Burada sektörde sık duyduğumuz bir efsaneyi de çöpe atalım: “Hazır script kullanmıyorum, kendi yazdığım için güvendeyim.” Maalesef değil. SQL Injection, dil bağımsız bir mantık hatası. PHP, Node, Python, Java fark etmiyor; yanlış sorgu yapısı kullandıysan açıksın. Hatta dürüst olmak gerekirse, custom yazılımda genelde test eksikliği daha fazla olduğu için, kampanya ile gelen ucuz bir CMS’ten bile daha riskli olabiliyor.

İşin püf noktası şurada: SQL Injection, tek bir önlemle çözülen bir şey değil. Parametreli sorgu (prepared statement), input doğrulama, minimum yetkili veritabanı kullanıcıları, doğru hata yönetimi ve güvenlik duvarı hepsi birlikte çalıştığında anlamlı oluyor. Tek katmanlı savunma yerine, “üst üste koruma katmanları” mantığını benimsemek gerekiyor.

Yapılandırma ve Yönetim: Adım Adım

Kaynak Yönetimi – Limitleri Zorlamayın

Şöyle düşünün: SQL Injection doğrudan veriyi çalmak için kullanılabileceği gibi, dolaylı olarak sunucuyu kaynak anlamında boğmak için de kullanılabilir. Özellikle ağır JOIN içeren, indexsiz, filtrelenmemiş sorgular varsa, saldırganlar bunları SQL Injection üzerinden çağırıp CPU’yu %100’e vurdurabilir. Sonra klasik destek bileti: “Sitem neden yavaş?”

Burada kritik nokta, sadece güvenliği değil, kaynak yönetimini de düşünmek. Veritabanı sorgularını izlemek (slow query log), sorgu sayısını azaltmak, gerekli alanlara index atmak temel adımlar. SQL Injection Nedir? Veritabanınızı Nasıl Korursunuz? sorusunu cevaplarken performans boyutunu da atlamamak gerekiyor; çünkü yavaşlayan sistemler genelde daha çok hata verir, daha çok log üretir ve bu karmaşada güvenlik açıkları fark edilmeden kalabilir.

“Aşırı kaynak kullanımı” veya “yüksek I/O” uyarısı aldığınızda çoğu kişi direkt RAM veya CPU’ya bakıyor. Genelde ilk bakmanız gereken dosya ise uygulamanın log dosyaları oluyor. Apache/Nginx access log ve veritabanı logları, şüpheli veya tekrar eden sorguları, garip parametrelerle gelen istekleri hemen ele verir. Bazı saldırılarda, tek endpoint’e sürekli farklı SQL payload’ları ile istek atıldığını net şekilde görürsünüz.

Güvenlik Duvarı ve Port Ayarları

Dış dünyaya açık her port, açık bir penceredir. Veritabanı güvenliğinden bahsederken, sadece kod tarafını düşünmek büyük hata. MySQL veya PostgreSQL doğrudan internete açıksa, iş zaten yanlış yerden başlamış demektir. Veritabanı servisini genellikle sadece localhost’a veya uygulama sunucusuna özel özel bir internal ağa dinletecek şekilde ayarlamak gerekiyor.

Güvenlik duvarı (iptables, firewalld veya cloud firewall) kullanarak sadece belirli IP’lerin belirli portlara erişmesine izin vermek basit ama etkili bir katman. SQL Injection’ı tamamen durdurmaz ama saldırı yüzeyini ciddi şekilde daraltır. Özellikle 3306 (MySQL), 5432 (PostgreSQL) gibi portların dünyaya açık olduğu senaryolardan kesinlikle kaçınmak lazım.

SSH ve FTP tarafında da benzer mantık geçerli. Şöyle yapın: SSH portunu varsayılan 22’den farklı bir porta alın, şifreli giriş yerine anahtar tabanlı (key-based) doğrulama kullanın, FTP yerine mümkünse SFTP’ye geçin ve kullanmadığınız servisleri kapatın. Dürüst olmak gerekirse, bir sunucuda “neden hala açık olduğunu kimsenin bilmediği” servisler genelde en zayıf halkayı oluşturuyor.

Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi

En güncel sürüm her zaman en iyisi mi? Güvenlik açısından bakarsak, evet, genelde öyle. Ama üretim ortamında “hemen” güncellemek yerine, önce test ortamında denemek şart. Özellikle PHP, framework ve veritabanı sürümleri arasındaki uyumsuzluklar, bazı güvenlik kütüphanelerinin çalışmamasına yol açabiliyor. Sonra farkında olmadan prepared statement yerine eski, güvensiz fonksiyonları kullanmaya geri dönülüyor.

Veritabanı optimizasyonu için bir altın kural verelim: “Her dinamik sorgunun, net bir amacı ve sınırlaması olmalı.” Kullanıcıdan gelen input’ları direkt SELECT * FROM tablo WHERE kolon = '$degisken' şeklinde birleştirmek yerine, daima parametreli sorgu kullanmak gerekiyor. Bu sadece güvenlik için değil; query cache, plan cache ve index kullanımı açısından da daha sağlıklı.

SQL Injection Nedir? Veritabanınızı Nasıl Korursunuz? sorusunun pratik tarafında da, kullanılan dilin sunduğu modern veri erişim katmanlarını (PDO, mysqli prepared statements, ORM’ler, query builder’lar) doğru konfigüre etmek yatıyor. Eski, deprecated fonksiyonlar (mesela mysql_* ailesi) hala hayatınızdaysa, önce orayı temizlemek şart.

Uygulama: Kurulum ve Yayına Alma

Terminali açın, şu komutu girin demiyorum ama mantık şu: Güvenli bir veritabanı ve uygulama ortamı hazırlarken, önce altyapı bağımlılıklarını netleştirmeniz gerekiyor. Hangi PHP sürümü, hangi veritabanı, hangi extension’lar, hangi güvenlik modülleri (mod_security, WAF vb.) kullanılacak? Bunları belirleyip bir “standart” çıkarmak, her yeni proje için sıfırdan düşünme derdini ortadan kaldırıyor.

Ardından config dosyalarındaki kritik satırlara odaklanın: Veritabanı kullanıcı adı ve şifresi, veritabanı kullanıcısının yetkileri, hata gösterimi (display_errors) ve loglama ayarları. Örneğin, üretim ortamında SQL hatalarını ekrana bastırmak, saldırgana adeta rehberlik etmiş oluyorsunuz. Hata olup olmadığını anlamak için kullanıcıya değil, log dosyasına güvenmek gerekiyor.

Genelde iyi yapılandırılmış bir ortam kurmak 5 dakikadan fazla sürmez, ama o 5 dakikada doğru kararları vermek önemli. Küçük ama kritik adımlar: veritabanı kullanıcısına sadece ilgili veritabanına erişim vermek, DROP ve ALTER gibi komutlara gerçekten ihtiyacınız var mı diye düşünmek, application-level firewall veya WAF eklemek. Eğer barındırma tarafında yönetilen bir hizmet kullanıyorsanız, örneğin güvenlik odaklı web hosting ya da izole kaynaklı bir VDS, bu ayarların bir kısmı zaten sizin yerinize düşünülmüş oluyor.

Bu arada, performansınızı artırmak ve saldırı yüzeyini küçültmek için Güvenlik sayfamızdaki diğer çözümlere de bakabilirsiniz. SQL Injection tek başına ele alınacak bir konu değil; SSL, doğru domain yönetimi, güvenli e-posta ve DNS yapılandırmasıyla birlikte düşünmek gerekiyor.

Sık Karşılaşılan Sorunlar ve Pratik Çözümler

SQL Injection özelinde sık görülen bir senaryo da şu: “Bazen login oluyor, bazen olmuyor, bazen de garip hata veriyor.” Çoğu zaman arka tarafta string birleştirme ile yazılmış, input’u düzgün escape etmeyen bir SQL sorgusu çalışıyor. Kullanıcı adı içine tek tırnak, çift tırnak, noktalı virgül gibi karakterler girildiğinde sorgu yapısı bozuluyor ve uygulama beklenmedik davranış gösteriyor.

Pratik yaklaşım şu olabilir: Önce şüpheli endpoint’leri (login, arama, filtreleme, admin işlemleri) belirleyin. Sonra bu alanlara bilinçli olarak problemli karakterler girip, logları takip edin. Eğer hata mesajında “SQL syntax” benzeri ifadeler görüyorsanız, orada muhtemelen SQL Injection’a açık bir nokta vardır. Parametreli sorguya geçerek ve input doğrulaması ekleyerek bu tür sorunları kökünden çözebilirsiniz.

Sıkça Sorulan Sorular

SQL tabanlı bir site güvenli mi?

SQL tabanlı bir site güvenli mi?
Evet, SQL tabanlı bir site gayet güvenli olabilir; mesele SQL kullanmak değil, nasıl kullandığınız. SQL Injection Nedir? Veritabanınızı Nasıl Korursunuz? sorusunun güvenlik tarafındaki cevabı basit: Parametreli sorgu, doğru yetkilendirme, güncel yazılım sürümleri ve güvenlik duvarı birlikte kullanıldığında, risk büyük oranda kontrol altına alınır. Ek önlem olarak, mutlaka SSL kullanın; hem veri şifrelemesi sağlar hem de tarayıcı ve arama motoru tarafında artı puan kazandırır. İhtiyacınız varsa uygun çözümler için SSL sertifikası hizmetlerine de göz atabilirsiniz.

Fiyat/Performans dengesini nasıl kurarız?

Fiyat/Performans dengesini nasıl kurarız?
Sadece “en ucuz sunucu”yu seçip, üzerine hiç güvenlik katmanı eklemezseniz, tasarruf ettiğiniz parayı bir güvenlik ihlali sonrası kaybedebilirsiniz. İşin dengesi şöyle: Uygulama tipinize göre doğru kaynakta (örn. izole kaynaklı cloud sunucu veya VDS), düzenli yedekleme, güvenlik güncellemeleri ve temel WAF kullanan bir yapı, çoğu proje için ideal fiyat/performans dengesini sağlar. Donanımı şişirmek yerine, yazılım katmanındaki güvenlik ve optimizasyona yatırım yapmak genelde daha mantıklıdır.

Taşıma (Migration) işlemi zor mu?

Taşıma (Migration) işlemi zor mu?
Eğer elinizde düzgün bir yedek ve net bir plan yoksa, evet, can sıkıcı olabilir. Özellikle veritabanı taşıma sırasında karakter seti, collation ve bağlantı ayarları bozulduğunda, SQL tarafında beklenmedik hatalar çıkabiliyor. Ama doğru araçlarla ve biraz disiplinle, süreç gayet yönetilebilir. Biz Bilhost tarafında, barındırma hizmetlerimize geçmek isteyen kullanıcılar için taşıma sürecini olabildiğince otomatikleştiriyoruz; veritabanı, dosyalar ve temel yapılandırma mümkün olduğunca kesintisiz şekilde aktarılıyor. Senin açından genelde “erişim bilgilerini ver, gerisini biz halledelim” seviyesine kadar indiriyoruz diyebilirim.

Sonuç

İşin özü şu: SQL Injection, havalı bir hacker teriminden ibaret değil; yanlış yazılmış tek bir sorgunun, tüm veritabanını tehlikeye atması demek. Ama gözünüzde büyütmeyin. Doğru sorgu yapısı, parametre kullanımı, sağlam bir veritabanı yapılandırması ve temel güvenlik katmanlarıyla bu riski oldukça makul seviyelere indirebilirsiniz. Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma gerçekten hayat kurtarır. Eğer bir yerde takılırsanız biz buradayız, yorumlarda sorularınızı bekliyorum.