E-pin Satış Scriptinde Tek Bir Kesme İşareti Neden Bütün Stoğunu Dışarı Sızdırır: Parametreli Sorgu Disiplininin Anlatılmayan Tarafı

Pek çok işletme sahibi SQL enjeksiyonunu geçmişte kalmış bir konu sanır. "Artık herkes hazır kütüphane kullanıyor, o iş çözüldü" diye düşünür. Gerçek şu ki, e-pin ve dijital ürün satan panellerde bu açık hâlâ en yıkıcı sonuçları üreten kalem. Nedeni teknik değil, ticari: senin veritabanında sadece müşteri bilgisi durmuyor. Satılmamış kodlar, tedarikçi maliyetleri, bayi cüzdan bakiyeleri ve ödeme sağlayıcı kimlikleri aynı çatının altında. Bu tabloyu okuyabilen biri, sunucuya hiç dokunmadan işinin tamamını kopyalayabilir.

Asıl mesele de burada. Enjeksiyon çoğu zaman "panele girme" niyetiyle değil, veriyi dışarı çekme niyetiyle yapılır. Saldırgan yönetici şifresini kırmakla uğraşmaz; bir arama kutusu, bir sıralama parametresi veya bir kampanya filtresi üzerinden veritabanına soru sormaya başlar. Bu yazıda, bir e-pin satış scriptinde enjeksiyonun hangi noktalardan girdiğini, parametreli sorgu disiplininin tam olarak neyi çözüp neyi çözmediğini ve kendi panelini nasıl sınayabileceğini anlatacağım.

Enjeksiyon hangi kapıdan giriyor, sandığın yerden mi?

İnsanlar risk aradığında giriş formuna bakar. Oysa giriş formu genellikle en çok ilgi gören, dolayısıyla en çok sertleştirilen yer. Sahada asıl açıkların çıktığı noktalar çok daha sıkıcı ekranlarda saklı: ürün listesindeki sıralama parametresi, bayi raporundaki tarih aralığı, sipariş arama kutusundaki serbest metin, kampanya kodu doğrulama ucu, dış sistemlerden gelen bildirim adresleri ve toplu içe aktarma ekranı.

Bu ekranların ortak özelliği var: hepsi kullanıcı girdisini alıp bir sorgunun içine yerleştiriyor ve hiçbiri "hassas" görünmüyor. Bir tarih filtresinin ne zararı olabilir ki? Eğer o tarih değeri sorguya metin birleştirmeyle ekleniyorsa, zararı bütün kod tablosunu satır satır okumak kadar olabilir. Bir dijital ürün satış yazılımında risk envanteri çıkarırken kural şu olmalı: dışarıdan gelen her değer, kim gönderdiğine bakılmaksızın güvenilmezdir. Buna kendi bayinin gönderdiği API isteği de, ödeme sağlayıcının bildirim çağrısı da dahil.

Parametreli sorgu tam olarak neyi çözüyor?

Parametreli sorgunun mantığı, sorgunun yapısını ve verisini birbirinden ayırmaktır. Sorgu şablonunu veritabanına önce gönderirsin; veritabanı onu derler ve yapının ne olduğuna karar verir. Sonra değerleri ayrı bir kanaldan iletirsin. O andan sonra değerin içinde ne olduğu önemsizdir; kesme işareti, yorum işareti, birleştirme ifadesi, hepsi düz metin olarak muamele görür. Çünkü yapı çoktan sabitlenmiştir ve veri, yapıyı değiştirme yetkisine sahip değildir.

Bu, kaçışlama fonksiyonlarından temelde farklı bir yaklaşım. Kaçışlama, tehlikeli karakterleri tanıyıp etkisizleştirmeye çalışır; yani bir tahmin işidir ve karakter kümesi uyuşmazlığı, çift kaçışlama veya eksik tırnak gibi durumlarda yanılabilir. Parametreli sorgu tahmin yapmaz, sınır çizer. Bu yüzden modern bir epin yazılım altyapısında beklenti, veri erişim katmanının tamamen hazırlanmış ifadeler üzerine kurulu olması ve metin birleştirmeyle sorgu üretiminin kod tabanında istisnasız yasak sayılmasıdır.

Parametre kullandım ama hâlâ açığım, nasıl olur?

Bu sorunun üç klasik cevabı var ve üçü de panellerde sık görülür. Birincisi, parametrenin çalışmadığı yerlerde ısrar etmek. Kolon adı, tablo adı, sıralama yönü ve limit ifadeleri yapısal öğelerdir; bunları parametre olarak geçemezsin. Doğru çözüm burada beyaz liste: kullanıcının gönderdiği "fiyat_artan" gibi bir etiketi, kod içinde tanımlı sabit bir sorgu parçasına eşlersin. Liste dışındaki her değer reddedilir.

İkincisi, arama sorgularında joker karakter mantığını bozmak. Değeri parametre olarak geçip yüzde işaretini şablonun içine yazmak yerine, değerin kendisini kullanıcı girdisiyle birleştirip parametre sanmak. Üçüncüsü ve en sinsisi, dinamik filtre üretimi. "Kullanıcı hangi filtreleri seçtiyse sorguya ekle" mantığıyla yazılan kodda, döngü içinde metin birleştirmeye dönülür ve parametre disiplini sessizce terk edilir. Bu üç tuzağı geçmenin tek yolu, kod tabanında sorgu üreten tek bir katman olması ve o katmanın dışında ham sorgu yazılmasının engellenmesi.

Kör enjeksiyon neden hata mesajı kapatmakla çözülmüyor?

Yaygın bir rahatlama yöntemi var: hata mesajlarını gizle, iş bitsin. Bu, saldırganın işini yavaşlatır ama durdurmaz. Kör enjeksiyonda saldırgan hata metnine ihtiyaç duymaz; sayfanın davranışını okur. Koşul doğruysa liste bir satır dönüyor, yanlışsa boş dönüyorsa, bu tek bitlik bilgi yeter. Her istekte bir bit öğrenerek tablo adlarını, kolon adlarını ve içeriği harf harf çıkarır.

Daha da sabırlı bir varyantı zaman tabanlı olanıdır. Sorguya bir bekleme koşulu iliştirir; sayfa iki saniye geciktiyse cevap "doğru", hemen döndüyse "yanlış" olur. Bu yüzden hata mesajlarını gizlemek bir hijyen maddesidir, savunma değil. Gerçek savunma yine aynı yerde: değerin sorgu yapısına hiç dokunamaması. Yanına eklenecek yararlı katmanlar ise sorgu başına oran sınırı, olağandışı uzun süren sorguların kayda geçmesi ve veritabanı kullanıcısının yetkilerinin dar tutulmasıdır.

Veritabanı hesabının yetkisi neden bu kadar önemli?

Diyelim ki bir açık gözden kaçtı. O noktada kaybın büyüklüğünü belirleyen tek şey, uygulamanın bağlandığı veritabanı hesabının neler yapabildiği. Eğer o hesap tablo silebiliyor, yeni kullanıcı oluşturabiliyor veya dosya okuyabiliyorsa, küçük bir açık toplam kayba dönüşür. Yetkisi okuma ve yazmaya sınırlanmış, şema değiştirme ve dosya erişimi kapatılmış bir hesapta aynı açık, zararlı ama kurtarılabilir bir olay olarak kalır.

Buna yedek disiplinini de ekle. Yedeğin var olması yeterli değil; geri yüklenebilir olması gerekiyor. Ayda bir kez yedeği ayrı bir ortama açıp sipariş, stok ve cüzdan tablolarının tutarlılığını kontrol etmek, bir felaket anında saatler yerine dakikalar kazandırır. Lisanslı bir e-pin yazılımı tercih etmenin pratik faydası da burada ortaya çıkıyor: bu yapılandırma kararları ilk kurulumda dokümante edilmiş hâlde gelir, sen her birini yeniden keşfetmek zorunda kalmazsın. Detayları özellik bölümünde görebilirsin.

Nereden başlamalısın, hangi sırayla?

İlk iş envanter. Veritabanına giden tüm noktaları listele; panel ekranları, arka plan görevleri, dış API uçları ve içe aktarma betikleri dahil. İkinci adım, bu noktaların hepsini tek bir veri erişim katmanının arkasına toplamak. Dağınık sorgu her zaman dağınık güvenlik demektir. Üçüncü adım, yapısal öğeler için beyaz liste eşlemelerini yazmak ve liste dışı değerlerde sessizce varsayılana dönmek yerine açıkça reddetmek.

Dördüncü adım doğrulama katmanı: sayısal alanlar gerçekten sayı mı, tarih biçimi doğru mu, listeden seçilen değer izinli kümede mi? Bu, enjeksiyonu engellemenin ikinci hattı olduğu gibi veri kalitesini de yükseltir. Beşinci ve son adım gözlem: yavaş sorguları, yüksek hacimli arama isteklerini ve olağandışı dönen kayıt sayılarını kayda al. Bu adımlar tamamlandığında panelin enjeksiyona karşı bağışıklık kazanmış olmayacak ama istismar edilebilir yüzeyi ciddi biçimde küçülmüş olacak. Lisans ve kurulum seçeneklerine fiyat sayfasından bakabilirsin.

Enjeksiyon konusunda rahatlamanın tek meşru yolu, panelinin veri katmanının nasıl kurulduğunu bilmek. "Güvenlidir" cümlesi bir taahhüt değil, bir temenni. Sorgu üretiminin tek bir yerden yürüdüğünü, filtre ve sıralama alanlarının beyaz listeyle işlendiğini ve veritabanı hesabının yetkisinin dar tutulduğunu kendi gözünle görmek istersen, panelin arama, rapor ve bayi ekranlarını canlı demo üzerinde deneyerek başlayabilirsin; kendi test girdilerini yazdığında ne olduğunu görmek, okuduğun her açıklamadan daha ikna edicidir.