Header Injection — attacker kiritgan qiymat HTTP, email yoki boshqa protokol header tuzilmasiga nazoratsiz qo‘shilib, yangi header yoki noto‘g‘ri semantika hosil qiladigan zaiflik. U web application, identity, protokol parsing yoki software supply chain xavfsizligida uchraydigan aniq tushunchani bildiradi. Atama xavfning nomini beradi, ammo real ta’sir application arxitekturasi, attacker imkoniyati, ishlatilgan kutubxona va operatsion nazoratga bog‘liq.
Protokol va koddagi o‘rni
Headerlar nom, ikki nuqta va qiymat qatorlaridan tashkil topadi. Agar application redirect URL, filename, user agent yoki email subjectni header qiymatiga filtrsiz joylasa, control character, line break yoki delimiter orqali qo‘shimcha header kiritilishi mumkin. Natija cookie overwrite, cache policy o‘zgarishi, response splitting yoki downstream parserda chalkashlik bo‘lishi mumkin.
Header Injection alohida zaiflik yoki hujum usuli sifatida ko‘rinsa ham, uning natijasi ko‘pincha boshqa qatlamdagi ishonch qaroriga ulanadi. Browser origini, reverse proxy, directory service, mail gateway, package registry yoki CI runner bir xil inputni turlicha talqin qilishi mumkin. Shu sabab tahlil faqat kod parchasini emas, butun data yo‘lini qamrab oladi.
Ajratish mezonlari
CRLF injection header injectionning keng tarqalgan texnik mexanizmidir, ammo header injection faqat CRLF bilan cheklanmaydi: protokolga xos delimiter, obs-fold yoki canonicalization farqi ham muammo yaratadi. Code injectiondan farqli ravishda maqsad odatda protokol metadata’sini o‘zgartirishdir.
Header Injection riskini kamaytirish uchun least privilege muhim. Parser yoki build jarayoni buzilgan taqdirda ham service account, CI token, directory bind yoki web worker minimal vakolatda bo‘lsa, zarar doirasi torayadi.
Testlar encoding, case folding, Unicode normalization, double decoding va proxy orqali o‘tish holatlarini qamrab oladi. Header Injection bir qatlamda xavfsiz ko‘rinsa ham, keyingi qatlam qiymatni qayta talqin qilishi mumkin.
Mitigatsiya
Header qiymatlari typed API orqali o‘rnatiladi, control characterlar rad etiladi va ruxsat etilgan formatlar allowlist qilinadi. Reverse proxy, framework va application bir xil canonicalizationga ega ekani tekshiriladi. Security headerlar user input bilan birlashtirilmaydi.
Header Injection uchun dokumentatsiya faqat “nima taqiqlangan” ro‘yxati emas, xavfsiz API namunasi va noto‘g‘ri API ishlatilganda nima yuz berishini ham ko‘rsatadi. Bu yangi kod yozishda xatoni takrorlash ehtimolini kamaytiradi.
Header Injection bo‘yicha xavf bahosi confidentiality, integrity, availability va accountability oqibatlari bo‘yicha ajratiladi. Ba’zi holatlarda asosiy zarar ma’lumot o‘qilishi emas, audit izining buzilishi, trusted update kanalining zaharlanishi yoki boshqa foydalanuvchi kontekstida amal bajarilishidir. Shuning uchun severity faqat payload murakkabligiga qarab belgilanmaydi.
Operatsion nazorat
False positive kamaytirish uchun nazorat payloadlari harmless bo‘ladi va productionda ehtiyotkorlik bilan ishlatiladi. Header Injectionni tekshirish hujumni takrorlashga emas, parser va policy qarorini kuzatishga qaratiladi.
Header Injection uchun sinovlar oddiy “yomon payload rad etildi” darajasida qolmaydi. Valid input, chegaraviy qiymat, noto‘g‘ri encoding, eski client, rollback, cache invalidation va monitoring signallari birga tekshiriladi. Tuzatishdan keyin tegishli log, alert va runbook yangilanmasa, keyingi incidentda muammo qayta kech aniqlanishi mumkin.
Operatsion amaliyotda owner, qabul mezoni va favqulodda javob tartibi oldindan yoziladi. Agar Header Injection supply chain yoki identity tizimiga taalluqli bo‘lsa, credential rotation, artefakt revoke, cache purge yoki user session invalidation kabi keyingi harakatlar ham rejaning bir qismi bo‘ladi.
Bog‘liq tushunchalar
HTTP header, CRLF injection, response splitting, cookie fixation, canonicalization, reverse proxy