Deserialization — text, binary yoki byte stream ko‘rinishidagi serialized ma’lumotni dastur ichidagi object va data structure’ga qayta aylantirish jarayoni.
Deserialization tashqi inputni runtime type va xotira obyektlariga aylantirgani sababli parsing, validation va security nuqtai nazaridan muhim boundary hisoblanadi.
Jarayon
Oddiy oqim:
baytlar
→ encoding decode
→ format parser
→ schema tekshiruvi
→ type conversion
→ object yaratish
→ business validation
Har bosqich boshqa turdagi xatoni aniqlaydi.
Format syntactically to‘g‘ri bo‘lsa ham business ma’noda yaroqsiz bo‘lishi mumkin.
Input manbalari
Deserialization quyidagi manbalarda ishlatiladi:
- HTTP request;
- message broker;
- database;
- cache;
- config fayl;
- session;
- uploaded file;
- inter-process communication;
- backup;
- clipboard.
Tashqi va eski storage inputi ishonchsiz deb qaraladi.
Parsing
Parser serialized format tuzilishini tekshiradi.
JSON misolida:
- qavs;
- quote;
- comma;
- number;
- escape;
- nesting
qoidalari tekshiriladi.
Syntax xato bo‘lsa object yaratish boshlanmaydi.
Schema validation
Schema fieldlar mavjudligi va type’ini tekshiradi.
Misol:
id — required integer
name — required string
age — optional non-negative integer
Schema validation business qoidaning faqat bir qismi.
age = 500 integer bo‘lsa ham domain uchun noto‘g‘ri bo‘lishi mumkin.
Type conversion
Formatdagi qiymat runtime type’ga o‘tadi.
Misollar:
- string → UUID;
- string → datetime;
- number → decimal;
- array → collection;
- object → class;
- integer → enum.
Conversion overflow, precision va locale’dan mustaqil bo‘lishi kerak.
Unknown field
Yangi sender eski receiver bilmaydigan field yuborishi mumkin.
Siyosat:
- e’tiborsiz qoldirish;
- extension mapda saqlash;
- warning;
- qat’iy xato.
Protocol versioning va security talabiga qarab tanlanadi.
Missing field
Required field yo‘q bo‘lsa xato.
Optional field:
- default;
- null;
- absent holat;
- computed value
olishi mumkin.
Missing va explicit null ma’nosi ajratiladi.
Object constructor
Deserializer constructorni chaqirishi yoki fieldlarni bevosita to‘ldirishi mumkin.
Bevosita field yozish:
- invariantni chetlab o‘tadi;
- private state’ni o‘zgartiradi;
- validationni bajarmaydi.
Xavfsiz model DTOga deserialize qilib, keyin domain factory orqali object yaratadi.
Polymorphic deserialization
Input type discriminator orqali subtype tanlashi mumkin.
{
"type": "card",
"number": "..."
}
Arbitrary class nomi bilan runtime object yaratish remote code execution xavfiga sabab bo‘lgan ko‘plab zaifliklarning manbai.
Faqat explicit allowlist va ma’lum factory ishlatiladi.
Unsafe native object format
Ayrim serializer object graph, class nomi va executable hooklarni saqlaydi.
Untrusted fayl deserialize qilinganda:
- constructor;
- property setter;
- callback;
- gadget chain;
- code loading
ishga tushishi mumkin.
Faqat data formatlardan foydalanish va native object deserializationni ishonchli manba bilan cheklash kerak.
Gadget chain
Alohida class zararli bo‘lmasligi mumkin.
Ammo mavjud classlar deserialization callbacklari ketma-ketligi attacker nazoratidagi data bilan xavfli amal bajarishi mumkin.
Bu gadget chain.
Library allowlist va safe mode bunday type’larni bloklaydi.
Resource exhaustion
Kichik ko‘ringan input katta resurs sarflashi mumkin.
Misollar:
- juda chuqur nesting;
- ulkan array length;
- duplicate object;
- compression bomb;
- katta string;
- recursive reference;
- hash collision.
Limitlar:
- input size;
- depth;
- object count;
- string length;
- collection length;
- vaqt;
- memory.
Duplicate key
JSON objectda bir xil key bir necha marta kelishi mumkin.
Parserlar:
- birinchi qiymatni oladi;
- oxirgi qiymatni oladi;
- xato beradi;
- barcha qiymatni saqlaydi.
Security filter va application boshqa siyosat ishlatsa validation bypass yuz beradi.
Number
Katta integer floatga aylantirilsa precision yo‘qoladi.
Misol:
- 64-bit ID;
- pul qiymati;
- timestamp;
- cryptographic counter.
Schema aniq integer width yoki decimal string talab qiladi.
Date
Datetime parsing:
- format;
- timezone;
- offset;
- leap day;
- precision;
- invalid local time
ni tekshiradi.
Locale-dependent date string API input uchun noaniq.
Validation
Deserializationdan keyingi business validation:
- ownership;
- permission;
- state transition;
- unique constraint;
- mavjud reference;
- limit;
- cross-field qoida
ni tekshiradi.
Type-safe object yaratilgani request bajarishga ruxsat berilganini anglatmaydi.
Partial update
PATCH requestda field holatlari uch xil bo‘lishi mumkin:
- yuborilmagan;
- null yuborilgan;
- qiymat yuborilgan.
Oddiy nullable property bu uch holatni ajrata olmasligi mumkin.
Optional wrapper yoki field presence metadata ishlatiladi.
Error xabari
Deserialization xatosi:
ni ko‘rsatishi mumkin.
Clientga internal class nomi yoki stack trace chiqarilmaydi.
Streaming deserialization
Katta file yoki message to‘liq xotiraga olinmasdan bosqichma-bosqich parse qilinadi.
Afzalliklari:
- kam memory;
- erta processing;
- backpressure.
Kamchiligi — keyingi field oldingi qarorni o‘zgartirsa state boshqaruvi murakkab.
Version migration
Uzoq saqlangan serialized data eski schema’da bo‘lishi mumkin.
O‘qish jarayoni:
- versionni aniqlaydi;
- eski formatni parse qiladi;
- migration bosqichlarini qo‘llaydi;
- joriy modelga aylantiradi.
Har eski versiyani domain objectga to‘g‘ridan-to‘g‘ri map qilish o‘rniga aniq migration qatlamlari ishlatiladi.
Observability
Deserialization uchun:
metriclari kuzatiladi.
Raw maxfiy payload logga yozilmaydi.
Taint chegarasi
Deserialized field type-safe bo‘lsa ham tashqi manbadan kelgan tainted data sifatida qaraladi. Uni file path, HTML, shell command yoki database query kontekstida ishlatishda mos encoding va ruxsat tekshiruvi bajariladi.
Fail-closed siyosati
Securityga ta’sir qiluvchi permission, role yoki signature field parse qilinmasa, tizim permissive defaultga o‘tmaydi. Xato requestni rad etadi va audit hodisasi yaratadi.
Bog‘liq tushunchalar
Serialization, Parser, Schema validation, DTO, Type conversion, Polymorphism, Gadget chain, Input validation, JSON, Object mapping