Merhaba. Önceki dersimizde, bir saldırganın doğrudan bir sonuç görmese bile veritabanını dolaylı yollarla nasıl sorgulayabildiğini, yani Blind SQL injection ve Out-of-Band (OAST) veri sızdırma tekniklerini derinlemesine analiz ettik. Bu saldırılarda ortak olan nokta, gönderilen zararlı girdinin (payload) anında işlenmesi ve bir şekilde geri bildirim alınmasıydı.
Bu dersimizde ise, zaman ve mekan kavramlarını ayırarak çok daha gizli ve tespiti zor bir saldırı türüne odaklanacağız: İkinci dereceden enjeksiyon (second-order injection) saldırıları. Bu saldırı türünde, zararlı girdi uygulamaya ilk enjekte edildiğinde "uykuya yatar" ve daha sonra, uygulamanın bambaşka bir bölümünde, tamamen farklı bir bağlamda "uyandırılarak" zafiyeti tetikler. Bu "saatli bomba" mekanizması, geleneksel statik analiz araçlarının ve yüzeysel kod incelemelerinin kolayca gözden kaçırabileceği bir zafiyet sınıfı oluşturur. Amacımız, bu gizli veri akışlarını takip ederek kod incelemesi sırasında ikinci dereceden enjeksiyon zafiyetlerini nasıl tespit edeceğimizi öğrenmektir.
İkinci Dereceden Enjeksiyonun Anatomisi
İkinci dereceden bir enjeksiyon saldırısı, adından da anlaşılacağı gibi, iki temel aşamadan oluşur:
- Depolama (Storage) Aşaması: Saldırgan, zararlı bir veri parçasını (payload) uygulama aracılığıyla kalıcı bir veri deposuna (Persistent Data Store - PDS) kaydeder. Bu depo bir veritabanı tablosu, bir oturum (session) dosyası, bir log dosyası veya hatta bir konfigürasyon dosyası olabilir. Bu aşamada, uygulama veriyi ilk işlediği bağlama göre bazı temizleme (sanitization) işlemlerinden geçirebilir. Ancak bu temizleme, verinin gelecekte kullanılacağı bağlam için yetersiz kalabilir.
- Yürütme (Execution) Aşaması: Uygulamanın farklı bir işlevi veya hatta tamamen farklı bir uygulama, depolanmış bu zararlı veriyi PDS'den okur ve güvenli olmayan bir şekilde kullanır. Veri, bu yeni bağlamda bir hassas hedefe (sensitive sink) ulaştığında asıl zafiyet tetiklenir.
Bu ayrım, zafiyetin tespitini zorlaştıran temel faktördür. Veri akışı, kaynak -> hedef şeklinde tek bir istekte tamamlanmaz; kaynak -> PDS ve PDS -> hedef olmak üzere iki ayrı ve zamansal olarak kopuk akışa bölünür.
[PDF] Second Order Code Injection Attacks - NCC Group
Bu klasikleşmiş NCC Group raporu, ikinci dereceden kod enjeksiyonu kavramını tanımlayan temel kaynaklardan biridir. Saldırının mantığını ve geleneksel enjeksiyonlardan farkını net bir şekilde ortaya koyar.
Lütfen PDF'in aşağıdaki bölümlerini inceleyin: Abstract (Özet): Bu bölüm, zafiyetin tanımını yapar: zararlı kodun hemen yürütülmeyip depolanması ve daha sonra başka bir bağlamda çağrılıp tetiklenmesi. Section 2: Understanding Second-order Code Injection: Bu paragraf, konsepti daha da açar ve zafiyeti tetikleyen uygulamanın, veriyi ilk depolayan uygulamadan farklı olabileceğini vurgular. Bu, özellikle mikroservis mimarilerinde ve entegre sistemlerde önemli bir risktir. 2.1. Categorising Second-order Code Insertion: Bu sınıflandırma bölümünü gözden geçirin. Saldırıların nasıl farklı senaryolarda (istatistiksel veriler, destek uygulamaları, basamaklı gönderimler) ortaya çıkabileceğini göstererek düşünce yapınızı genişletecektir.
Kod İncelemesinde Veri Akışını Takip Etmek
İkinci dereceden bir zafiyeti tespit etmek için, kod incelemesi sırasında zihinsel modelimizi değiştirmemiz gerekir. Sadece kullanıcıdan gelen girdinin anında bir SQL sorgusuna veya echo ifadesine gidip gitmediğine bakmak yetersizdir. Bunun yerine, kalıcı veri depolarını (PDS) birer "aracı" olarak görmeli ve iki aşamalı bir analiz yapmalıyız.
Aşağıdaki akademik makale, bu zafiyetleri statik kod analiziyle otomatik olarak tespit etme problemini ele alıyor. Yaklaşımları, manuel bir kod incelemesi için mükemmel bir yol haritası sunmaktadır.
[PDF] Static Detection of Second-Order Vulnerabilities in Web Applications
Bu USENIX makalesi, ikinci dereceden zafiyetlerin statik analizle nasıl tespit edilebileceğini teknik olarak detaylandıran önemli bir çalışmadır. Veri akışının PDS üzerinden nasıl modellendiğini anlamak, kod incelemesi pratiğiniz için çok değerlidir.
Lütfen aşağıdaki bölümlere odaklanın: 2.2 Second-Order Vulnerabilities: Bu bölüm, zafiyetin veri akışı modelini tanımlar. Bu tanım, analizin neden iki ayrı veri akışına odaklanması gerektiğini vurgular: kaynak -> PDS ve PDS -> sink. 2.2.1 Persistent Cross-Site Scripting: Bu bölüm, en yaygın ikinci dereceden zafiyet olan Kalıcı XSS'i açıklar. Listing 3'teki koda dikkat edin: $_POST['comment'] htmlentities() ile temizlenirken, $_POST['name'] (author olarak kaydedilir) hiçbir temizleme olmadan veritabanına yazılır. Daha sonra bu author alanı başka bir yerde echo ile basıldığında XSS tetiklenir. 2.2.2 Second-Order SQL Injection: Bu bölüm ve Listing 4'teki kod, ikinci dereceden SQLi için harika bir örnektir. Başarılı girişte kullanıcının adı ($_POST['user']) session'a ($_SESSION['user']) yazılır. Başarısız bir sonraki giriş denemesinde ise session'dan okunan bu kullanıcı adı, temizlenmeden bir INSERT sorgusuna dahil edilir.
Bu örneklerden de görüleceği üzere, asıl zorluk bu iki ayrı veri akışını birleştirebilmektir. Kod incelemesi yaparken kendimize sormamız gereken sorular şunlardır:
- Kullanıcı girdisi nerelerde saklanıyor? (Veritabanı tabloları, session değişkenleri, dosya adları, loglar vb.)
- Bu saklanan veri daha sonra nerelerde okunuyor?
- Okunan bu veri, yeni bağlamı için doğru bir şekilde temizleniyor mu?
Pratik Örnekler ve Vaka Analizleri
1. İkinci Dereceden SQL Injection
Kullanıcı tercihlerinin veya profil bilgilerinin daha sonra dinamik sorgularda kullanılması, bu zafiyet için yaygın bir senaryodur. Aşağıdaki kısa video, bu durumu çok net bir şekilde özetliyor.
Stealing Data with Second Order SQL Injection
Bu video, bir kullanıcının rapor sıralama tercihini veritabanına kaydetmesi ve bu tercihin daha sonra dinamik bir ORDER BY ifadesinde kullanılmasının nasıl ikinci dereceden SQLi'ye yol açtığını gösteriyor.
Lütfen videonun tamamını izleyin. Özellikle şu akışa dikkat edin: Depolama Aşaması: Kullanıcının sıralama tercihi, bir JSON nesnesi olarak veritabanına kaydedilir. Yürütme Aşaması: Raporu oluşturan saklı yordam (stored procedure), bu JSON değerini veritabanından okur, parse eder ve dinamik bir SQL sorgusunun ORDER BY bölümüne ekler. Saldırı: Saldırgan, depolanan JSON değerini manipüle ederek (ORDER BY ifadesini sonlandırıp yeni bir INSERT ifadesi ekleyerek) zararlı payload'ını enjekte eder. Rapor sorgusu çalıştığında, bu zararlı kod da yürütülür.
Gerçek dünyadan bir WordPress eklentisi zafiyetinin akış şeması da bu modeli mükemmel bir şekilde göstermektedir:
Bu şemada, sanitize_text_field fonksiyonu veriyi HTML bağlamı için güvenli hale getirmeye çalışırken, SQL bağlamı için gereken temizliği yapmaz. Veri bu "kısmen temizlenmiş" haliyle daha sonra sorguya dahil edildiğinde zafiyet ortaya çıkar.
2. İkinci Dereceden NoSQL Injection
Bu saldırı paterni sadece SQL veritabanları ile sınırlı değildir. Modern uygulamalarda sıkça kullanılan NoSQL veritabanları da benzer şekilde risk altındadır. Aşağıdaki video, e-posta değiştirme fonksiyonu üzerinden tetiklenen zekice bir ikinci dereceden NoSQL enjeksiyonu vakasını adım adım anlatmaktadır.
Second order NoSQL injection? - Solution to January '23 Challenge
Intigriti tarafından hazırlanan bu challenge çözümü, ikinci dereceden bir NoSQL enjeksiyonunun nasıl tespit edilip istismar edildiğini gösteriyor.
Lütfen videonun şu bölümlerini izleyin: Zafiyetin Keşfi (Keşif anı): Konuşmacı, e-posta adresini zararlı bir NoSQL sorgu operatörü içeren bir değerle günceller. Bu bir depolama aşamasıdır. Daha sonra, arkadaş arama fonksiyonunu kullandığında, arka planda çalışan sorgunun bu depolanmış zararlı e-posta adresini kullanarak beklenmedik bir sonuç döndürdüğünü fark eder. Bu da yürütme aşamasıdır. İstismar (Veri sızdırma): Bu "evet/hayır" mekanizmasını kullanarak, this.password.match gibi MongoDB'ye özgü regex operatörleri enjekte eder. Bu sayede, başka bir kullanıcının parolasını karakter karakter sızdırmayı başarır.
Kod İncelemesi Stratejisi
İkinci dereceden zafiyetleri sistematik olarak bulmak için kod incelemesi yaklaşımımızı şu şekilde yapılandırabiliriz:
-
Güvenilmez Veri Depolarını Belirleyin: Uygulamadaki tüm kalıcı veri depolarını (PDS) haritalandırın.
- Veritabanları: Hangi tabloların hangi kolonları kullanıcı girdisi depoluyor? (
users.username,comments.body,user_preferences.settings_jsonvb.) - Oturum Değişkenleri: Hangi
$_SESSIONanahtarları kullanıcıdan gelen veriyi tutuyor? ($_SESSION['username'],$_SESSION['last_viewed_item']vb.) - Dosya Sistemi: Kullanıcıların yüklediği dosyalar, oluşturduğu dizinler veya log dosyaları nerede saklanıyor?
- Veritabanları: Hangi tabloların hangi kolonları kullanıcı girdisi depoluyor? (
-
"Kirli" Depoları İşaretleyin (Source -> PDS): Kod tabanında, dış kaynaklardan (ör.
$_POST,$_GET,file_get_contents('php://input')) gelen verilerin bu PDS'lere yazıldığı tüm noktaları bulun. Bu yazma işlemi sırasında uygulanan temizleme fonksiyonlarını not alın. Bu temizlemenin sadece anlık bağlam için mi yoksa genel bir koruma mı sağladığını sorgulayın. -
Riskli Okuma Noktalarını Bulun (PDS -> Sink): Kod tabanında, bu PDS'lerden veri okunan ve hassas hedeflere (SQL sorguları,
eval,exec,echo,includevb.) aktarılan tüm noktaları tespit edin.
- Akışları Birleştirin: "Kirli" olarak işaretlediğiniz bir PDS konumundan veri okunup, hassas bir hedefe yeterli temizleme yapılmadan ulaşıyorsa, potansiyel bir ikinci dereceden zafiyet buldunuz demektir.
Bu süreç, temel olarak "veritabanından veya session'dan gelen veriye güvenme" ilkesine dayanır. Her veri parçası, bir hassas fonksiyonda kullanılmadan hemen önce, o fonksiyona özel bağlam için (context-aware) temizlenmelidir.
Sonuç
Bu dersimizde, enjeksiyon saldırılarının daha gizli ve karmaşık bir yüzünü, ikinci dereceden enjeksiyonları inceledik. Bu zafiyetlerin, saldırının depolama ve yürütme aşamalarını birbirinden ayırarak geleneksel tespit yöntemlerinden nasıl kaçabildiğini gördük.
Ana Çıkarımlar:
- İkinci Dereceden Enjeksiyon, zararlı girdinin kalıcı bir veri deposunda saklanması ve daha sonra farklı bir bağlamda tetiklenmesiyle gerçekleşen iki adımlı bir saldırıdır.
- Kod incelemesindeki en büyük zorluk, bu zamansal ve mekansal olarak ayrılmış
kaynak -> PDSvePDS -> hedefveri akışlarını birleştirmektir. - Temel savunma prensibi, depolanan veriyi "güvenli" olarak varsaymamaktır. Veri, bir hassas hedefte kullanılmadan hemen önce, o hedefin gerektirdiği bağlama uygun şekilde temizlenmelidir.
- Kullanıcı profil bilgileri, ayarlar, yorumlar, loglar gibi depolanan her türlü veri potansiyel bir saldırı vektörü olarak değerlendirilmelidir.
Önceki dersimizde veritabanı sorgularının mantığını manipüle etmeyi öğrendik. Bu dersimizde ise bu manipülasyonun gecikmeli olarak nasıl yapılabileceğini gördük. Bir sonraki dersimizde, veri katmanından sunum katmanına geçerek, web uygulamalarının dinamik içerik oluşturmak için kullandığı şablon motorlarını hedef alan ve genellikle doğrudan uzaktan kod çalıştırmaya (RCE) yol açan Server-Side Template Injection (SSTI) saldırılarını analiz edeceğiz.