NoSQL Enjeksiyonu: Saldırılar ve Savunmalar

SQL Injection'dan Farkı: Sentaks vs. Mantık

SQL enjeksiyonu genellikle sorgu sentaksını (syntax) kırmaya dayanır; yani bir string ifadeden çıkıp (') yeni SQL komutları eklemek üzerine kuruludur. NoSQL enjeksiyonu ise, özellikle MongoDB gibi JSON benzeri BSON (Binary JSON) dökümanları ile çalışan veritabanlarında, çoğunlukla sorgu mantığını (logic) manipüle etmeye odaklanır.

Uygulama kodu, kullanıcıdan gelen verileri bir sorgu nesnesi oluşturmak için kullandığında zafiyet ortaya çıkar. Örneğin, bir Node.js uygulamasında kod şöyle olabilir:

// GÜVENSİZ KOD
let username = req.body.username; // Kullanıcıdan gelen: "admin"
let password = req.body.password; // Kullanıcıdan gelen: "123456"

// Kullanıcı girdisi doğrudan sorgu nesnesine yerleştiriliyor
db.collection('users').findOne({
  username: username,
  password: password
}, function(err, user) {
  // ...
});

Bu kod parçası ilk bakışta zararsız görünebilir. Ancak, password alanına "123456" gibi bir string yerine {"$ne": "dummy"} gibi bir JSON nesnesi gönderilirse ne olur? Sorgu şu hale dönüşür:

db.collection('users').findOne({
  username: "admin",
  password: {"$ne": "dummy"} // Parolası "dummy" OLMAYAN kullanıcıyı bul
});

Bu sorgu, admin kullanıcısının parolasının dummy olmaması durumunda (ki büyük ihtimalle öyledir) başarılı olur ve kimlik doğrulama atlatılmış olur. Saldırgan, sorgunun yapısını değil, içerdiği mantıksal operatörü kontrol etmiştir. İşte bu, NoSQL enjeksiyonunun temelini oluşturan operatör manipülasyonudur.

Saldırı Vektörleri ve Operatör Manipülasyonu

NoSQL saldırıları genellikle iki ana kategoriye ayrılır:

1. Syntax Injection: Geleneksel SQLi'ye daha çok benzer. Kullanıcı girdisi, bir string birleştirme yoluyla sorguya eklenir ve tırnak ('), noktalı virgül (;) gibi özel karakterler kullanılarak sorgu sentaksı kırılmaya çalışılır. Bu, özellikle sorguların metin tabanlı olarak oluşturulduğu eski veya daha az güvenli framework'lerde görülebilir.
2. Operator Injection: Daha yaygın ve NoSQL'e özgü olan türdür. Kullanıcı girdisi, sorguyu oluşturan nesnenin bir parçası olarak yorumlanır ve saldırgan, $ ile başlayan MongoDB operatörlerini ($ne, $gt, $in, $regex, $where vb.) enjekte ederek sorgunun davranışını değiştirir.

Şimdi bir kimlik doğrulama atlatma senaryosunu pratik olarak görelim.

Bu saldırının kod seviyesindeki yansıması aşağıdaki gibidir. Kullanıcıdan gelen search parametresi, sorgunun _id alanına doğrudan atanır. Eğer saldırgan search[ne]=1 gibi bir parametre gönderirse, PHP bunu bir diziye dönüştürür ve MongoDB sorgusu _id'si 1'e eşit olmayan tüm kayıtları döndürür.

İleri Seviye İstismar: Blind NoSQL Injection ile Veri Sızdırma

Saldırganlık ve pentest deneyiminizden bildiğiniz gibi, zafiyetler her zaman doğrudan bir sonuç döndürmez. Tıpkı Blind SQLi gibi, Blind NoSQL Injection da mevcuttur. Bu senaryoda, uygulamanın yanıtındaki küçük farklılıklara (örneğin "login successful" vs "login failed") veya yanıt sürelerindeki gecikmelere dayanarak veri sızdırılır.

Bu teknikte en sık kullanılan operatörlerden biri $regex'tir. Saldırgan, bir parolanın veya gizli bir bilginin karakterlerini tek tek tahmin etmek için düzenli ifadeler kullanır.

Örneğin, admin kullanıcısının parolasını bulmak için şöyle bir payload gönderilebilir:
{"username": "admin", "password": {"$regex": "^a.*"}}

Bu sorgu, parolası "a" ile başlayan admin kullanıcısını arar. Eğer uygulama başarılı bir yanıt dönerse, ilk karakterin "a" olduğu anlaşılır. Sonraki adım ^ab.* olur ve bu süreç parola tamamen bulunana kadar devam eder.

Daha gelişmiş senaryolarda, JavaScript çalıştırabilen $where operatörü gibi daha tehlikeli operatörler de enjekte edilebilir. Eğer uygulama bu operatörü filtrelemiyorsa, bu durum RCE'ye kadar varabilir.

Savunma Mekanizmalarının Tasarımı

Bir AppSec Mimarı olarak, bu tür zafiyetlere karşı katmanlı ve sağlam savunmalar tasarlamak en kritik görevinizdir. NoSQL enjeksiyonuna karşı savunma, SQLi'ye benzer şekilde, temel bir prensibe dayanır: Kullanıcı girdisinin, sorgunun yapısını veya mantığını kontrol etmesine asla izin vermemek.

HackTricks'teki listeden de yola çıkarak, temel savunma stratejilerini şöyle sıralayabiliriz:

1. Operatörleri Temizleme (Sanitization): En etkili yöntemlerden biri, kullanıcıdan gelen veride $ ile başlayan anahtarları (key) tamamen reddetmek veya temizlemektir. Bu, operatör enjeksiyonunu büyük ölçüde engeller. Node.js ekosisteminde express-mongo-sanitize veya mongo-sanitize gibi kütüphaneler bu işi otomatik olarak yapar. Mongoose ODM (Object Data Modeling) kullanılıyorsa, sanitizeFilter:true seçeneği bu davranışı etkinleştirir.

2. Sunucu Taraflı JavaScript'i Devre Dışı Bırakma: MongoDB'nin $where gibi JavaScript çalıştıran operatörleri oldukça tehlikelidir. Uygulamanız bu fonksiyonaliteye ihtiyaç duymuyorsa, MongoDB konfigürasyonunda sunucu taraflı script'lemeyi (--noscripting parametresi ile) tamamen devre dışı bırakmak, RCE riskini ortadan kaldırır. MongoDB'nin modern versiyonlarında bu varsayılan olarak kapalıdır.

3. Tip ve Şema Doğrulama (Schema Validation): Kullanıcıdan gelen verinin beklenen formatta (örneğin bir string, sayı vb.) ve yapıda olduğunu sıkı bir şekilde doğrulayın. Örneğin, parola alanı için bir string bekleniyorsa, {"$ne": ...} gibi bir nesnenin gelmesi engellenmelidir. Joi, Zod veya Ajv gibi şema doğrulama kütüphaneleri bu süreci otomatize etmek için idealdir. Bu, bir skaler değer beklenen yere bir dizi (array) enjekte edilerek yapılan [$ne] hilelerini de önler.

4. En Az Yetki Prensibi: Veritabanı kullanıcısının sadece uygulama için gerekli olan minimum yetkilere sahip olduğundan emin olun. Bu, bir enjeksiyon başarılı olsa bile saldırganın etki alanını sınırlar.

5. ORM/ODM Kullanımı ve Güvenli Konfigürasyon: Mongoose (Node.js), MongoEngine (Python) gibi ODM'ler, genellikle güvenli sorgu oluşturma yöntemleri sunar. Ancak, HackTricks'te belirtilen Mongoose CVE örneğinde olduğu gibi, bu kütüphanelerin kendilerinde de zafiyetler olabilir veya güvensiz kullanımlara (örneğin, populate ile match opsiyonunun dikkatsiz kullanımı) izin verebilirler. Bu nedenle, kullandığınız kütüphanenin güvenlik belgelerini ve en iyi pratiklerini takip etmek hayati önem taşır.

Özet ve Sonraki Adımlar

Bu dersimizde, modern uygulamalarda giderek daha fazla yer bulan NoSQL veritabanlarına yönelik enjeksiyon saldırılarını ele aldık.

Ana Çıkarımlar:

• NoSQL enjeksiyonu, genellikle SQLi gibi sorgu sentaksını kırmaktan ziyade, $ne, $regex gibi operatörleri enjekte ederek sorgu mantığını manipüle etmeye dayanır.
• Bu manipülasyon, kimlik doğrulama mekanizmalarını atlatmaktan, $regex gibi operatörlerle kör bir şekilde veri sızdırmaya kadar geniş bir yelpazede istismar edilebilir.
• En etkili savunma stratejisi, kullanıcı girdisinin sorgu nesnesinin yapısını ($key) kontrol etmesini engellemek için sıkı bir sanitizasyon ve şema doğrulaması uygulamaktır.
• Sunucu taraflı script'lemeyi devre dışı bırakmak ve güvenli ODM/kütüphane kullanımı, katmanlı savunmanın önemli parçalarıdır.

Bu dersle birlikte SQL, SSTI ve NoSQL gibi farklı katmanları ve paradigmaları hedef alan çeşitli enjeksiyon türlerini analiz etmiş olduk. Bir sonraki dersimizde, kurumsal ortamlarda sıkça karşılaşılan bir başka kritik servis olan LDAP (Lightweight Directory Access Protocol) dizin servislerine yönelik enjeksiyon saldırılarını inceleyeceğiz. LDAP sorgularının da kullanıcı girdisinden nasıl etkilenebileceğini ve güvenli LDAP filtrelerinin nasıl oluşturulması gerektiğini öğreneceğiz.