kullanici1
Mart 26, 2026

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, 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.
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.
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:
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.
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:
Ö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.