Insecure Deserialization Saldırıları Nedir?

Siber Güvenlik

Modern uygulamalar performans ve kullanım kolaylığı için nesneleri (object) seri hale getirip (serialize) ağ üzerinden taşır veya disk/cache üzerinde saklar. Oturum verisi, kuyruk mesajları, mikroservisler arası iletişim, state yönetimi ve bazı RPC yaklaşımları bu tekniği sık kullanır. Sorun, seri hale getirilen verinin daha sonra tekrar nesneye çevrilmesi (deserialize) sırasında, uygulamanın bu veriye “güvenmesi” ile başlar.

Insecure Deserialization, saldırganın kontrol edebildiği serileştirilmiş veriyi uygulamaya okutması ve bu işlem sırasında istenmeyen davranışlar tetiklemesidir. Etki; basit bir yetki atlatmadan uzaktan kod çalıştırmaya (RCE) kadar genişleyebilir. Bu zafiyet sınıfı özellikle framework’lerin otomatik nesne üretimi, refleksiyon (reflection) ve “gadget chain” adı verilen zincirleme çağrı örüntüleriyle birleştiğinde kritik seviyeye çıkabilir.

Serileştirme / Seriden Çözme Nedir?

Serileştirme, bir nesnenin bellekteki temsilini taşınabilir bir formata dönüştürme işlemidir. JSON, XML gibi metin tabanlı formatlar yanında; Java Serialization, .NET BinaryFormatter, PHP serialize(), Python pickle gibi ikili/nesne tabanlı formatlar da kullanılır. Seriden çözme ise bu formatı tekrar çalışır nesnelere dönüştürür. 

Güvenlik problemi, seriden çözme işleminin bazen yalnızca veri üretmemesi; aynı zamanda sınıf örneklemesi, özel metotların çağrılması (ör. magic methods), tip dönüştürme ve yan etkili fonksiyonların tetiklenmesi gibi davranışları otomatik yürütmesidir. Saldırgan, bu yan etkileri yönlendirerek beklenmeyen akışlar oluşturabilir.

Yaygın Insecure Deserialization Senaryoları

Bu zafiyet çoğunlukla ‘görünmez’ veri taşıma katmanlarında ortaya çıkar. En sık rastlanan senaryolar şunlardır:

1) İstemci Tarafı Taşınan Oturum/State Verileri: 
Uygulama, kullanıcı oturumunu veya state bilgisini şifrelenmemiş/imtzasız bir şekilde cookie içinde nesne formatında taşıyorsa, saldırgan bu içeriği değiştirip sunucuya geri gönderebilir. 

2) Mesaj Kuyrukları ve Event Tabanlı Sistemler: 
Kuyruk tüketicileri (consumer) gelen mesajları otomatik deserialize ediyorsa, kötü niyetli bir mesaj zincirleme etki doğurabilir. Bu risk, özellikle “güvenilir ağ” varsayımı yapılan iç sistemlerde artar. 

3) API’lerde Tip Zorlama (Type Confusion): 
API endpoint’leri JSON gibi formatlarda beklenen şemayı katı doğrulamazsa; saldırgan farklı tipler ve beklenmeyen alanlarla uygulama mantığını saptırabilir. Bu her zaman klasik “RCE” üretmez; ama yetki yükseltme, iş kuralı atlatma ve veri bütünlüğü sorunlarına yol açabilir. 

4) Framework Otomasyonu ve Gadget Chain’ler: 
Bazı ekosistemlerde, saldırganın seçtiği sınıfların belirli metotları seriden çözme sırasında tetiklenebilir. Uygulamada veya bağımlılıklarda bulunan ‘gadget’ sınıflar zincirlenerek istenmeyen komut çalıştırma veya dosya işlemleri gibi sonuçlara ulaşılabilir.

Etkiler ve Risk

Insecure Deserialization’in etkisi, uygulamanın kullandığı format, sınıf ekosistemi ve güvenlik kontrollerine bağlıdır. Tipik sonuçlar şunlardır: 

  • Uzaktankod çalıştırma (RCE): Uygun gadget zinciri varsa en kritik senaryodur. 
  • Yetki yükseltme / kimlik sahteciliği: Oturum nesnesi veya kullanıcı rolü manipüle edilebilir. 
  • İş kuralı atlatma: Ödeme, kupon, limit, onay akışları gibi mantıklar bozulabilir. 
  • Veri bütünlüğü ihlali: Kritik alanlar beklenmeyen değerlerle güncellenebilir. 
  • Hizmet kesintisi (DoS): Büyük nesneler, derin iç içe yapılar veya pahalı parse işlemleri kaynak tüketebilir. 

Bu nedenle bulgu değerlendirmesinde yalnızca ‘deseria lization var mı?’ değil; ‘hangi format, hangi kaynak, hangi trust boundary?’ soruları birlikte ele alınmalıdır.

Önleme ve Güvenli Tasarım Adımları

Bu zafiyeti azaltmanın en etkili yolu, güvenilmeyen veriyi nesne olarak geri üretmeyi mümkün olduğunca sınırlamaktır. Uygulanabilir önlemler:

  • Güvenilmeyenveri için ‘native object deserialization’ kullanma: Java/.NET/PHP gibi platformlarda riskli serializer’lardan kaçın; JSON gibi data-only formatları tercih et.
  • Katı şema doğrulama: Beklenen alanlar, tipler ve sınırlar için schema validation uygula; bilinmeyen alanları reddet. 
  • İmza ve bütünlük koruması: İstemciden dönen state/cookie verilerini imzala (HMAC) ve mümkünse şifrele; ‘tamper’ edilmeye dayanıklı yap. 
  • Allowlist yaklaşımı: Deserialize edilecek tipleri/sınıfları açıkça sınırla; dinamik sınıf yüklemeyi engelle. 
  • Güvenli kütüphane seçimi: Platformların ‘unsafe’ olarak işaretlediği serializer’ları (ör. bazı eski binary formatter yaklaşımları) devreden çıkar. 
  • İzolasyon ve ayrıcalık azaltma: Deserialize işlemini düşük yetkili bir bileşende çalıştır; dosya sistemi/komut çalıştırma yetkilerini minimize et. 
  • Gözlemleme ve rate limit: Şüpheli payload boyutlarını, hatalı parse oranlarını ve tekrar eden denemeleri izle; limit koy. 

Özetle Insecure Deserialization, çoğu zaman mimarinin “data mı, code mu?” ayrımını bulanıklaştırdığı noktada ortaya çıkar. Veri taşıma kanallarını sadeleştirmek, doğrulamayı katılaştırmak ve bütünlük koruması eklemek; bu sınıfın riskini belirgin biçimde düşürür.

Tags :
Deserialization,GadgetChains,WebGüvenliği
Share This :

Diğer Yazılar

Bize Soru Sorun

Soru ve görüşleriniz için bizimle iletişime geçebilirsiniz.