🔴 SQL Injection

SQL Injection: SQL Injection'ı, bir sekretere telefonda talimat dikte etmek gibi düşün. Sekretere dersin ki: 'Şu kişiye dosyayı gönder — adı: Ahmet'.

SQL Injection'ı, bir sekretere telefonda talimat dikte etmek gibi düşün. Sekretere dersin ki: 'Şu kişiye dosyayı gönder — adı: Ahmet'. Karşı taraf ismini söylerken 'Ahmet, ve bu arada bütün arşivi de faksla' derse, sekreter bunun ismin bir parçası mı yoksa yeni bir emir mi olduğunu ayırt edemez; çünkü ikisi de aynı ses kanalından, aynı cümlenin içinde gelmiştir. Veritabanı da string birleştirmeyle kurulmuş bir sorguda tam olarak bu sağırlıktadır: `' OR '1'='1` yazan kullanıcının girdisi, artık veri değil **komut** olur. Peki neden bu sorun 'tehlikeli karakterleri temizleyerek' çözülmüyor — tırnak işaretlerini filtrelemek yetmez mi? Yetmediği yıllarca acı biçimde öğrenildi: kara liste her zaman eksiktir (encoding varyasyonları, Unicode benzerleri, çok baytlı karakter setleri, yorum işaretleri). Asıl çözüm karakterleri kovalamak değil, **kanalı ayırmaktır**: parametreli sorguda cümlenin iskeleti veritabanına önce ve tek başına gider, kullanıcı verisi sonra ayrı bir kutuda ulaşır. Veri hangi karakteri içerirse içersin artık komut olma ihtimali yoktur — çünkü komutun okunacağı an çoktan geçmiştir. Java'daki `PreparedStatement` tam olarak bunun için vardır ve fark tek satırdadır: `"... WHERE user='" + name + "'"` savunmasızdır, `"... WHERE user=?"` + `setString(1, name)` ise yapısal olarak bağışıktır. Python'da `cursor.execute(sql, (name,))`, aynı fikir. QA açısından burada net bir sorumluluk var: bu, 'güvenlik ekibinin işi' diye devredilebilecek bir konu değil, her login/arama/filtre alanında koşulması gereken bir negatif test senaryosudur. `' OR '1'='1' --` girdisiyle giriş yapılabiliyorsa bu bir bug değil, incident'tır; ve bu tür açıklar production'a çıktıktan sonra değil, test aşamasında yakalandığında maliyeti binde birdir. Bir de şu kritik kural: injection testleri asla canlı veri üzerinde değil, izole bir test veritabanında koşulur.

SQL Injection & Parametreli Sorgular

Micro Lab: SQL — GROUP BY / CTE / Window

TODO satirini beklenen cozumdeki kritik satirla degistir. Bu gercek runtime degil; amac dogru yapinin yazilmasini kontrollu olarak pekistirmek.

Adim Adim: SQL — GROUP BY / CTE / Window

Aggregation mi Window mi?

Aggregation (ozetleme) mi Window (satir bazli hesap) mi? Onu belirle

Aggregation icin GROUP BY ile ozetlenecek sutunu sec

HAVING ile gruplara kosul uygula — WHERE gibi ama agregasyon sonrasinda

WITH cte_adi AS (...) SELECT ... FROM cte_adi ile sorguyu modülerlestir

OVER(PARTITION BY) ekle

Window icin SUM(col) OVER (PARTITION BY bolum ORDER BY siralama) kullan

SQL GROUP BY ve Window Function sorgusu yazma sirasi nedir?

ACID Transaction Akışı — DB İçinde Neler Oluyor