Injection — ishonchsiz input buyruq, query yoki interpreter sintaksisining bir qismi sifatida noto‘g‘ri talqin qilinishi natijasida yuzaga keladigan zaifliklar oilasi. Attacker data o‘rniga code yoki control structure yuborib, tizimning bajarilish mantiqini o‘zgartirishga urinadi.
Injection SQL, operating system command, LDAP, template, expression language, NoSQL, header va boshqa interpreterlarda uchrashi mumkin.
Data va code aralashuvi
Asosiy muammo user input bilan buyruq matni string concatenation orqali birlashtirilganda paydo bo‘ladi.
Masalan:
query = "SELECT ... WHERE name = '" + input + "'"
Interpreter qaysi qism developer yozgan code, qaysi qism user data ekanini ajrata olmaydi.
Parameterized interface bu chegarani saqlaydi.
SQL Injection
SQL query ichiga zararli sintaksis qo‘shilib:
- boshqa rowlarni o‘qish;
- authenticationni chetlab o‘tish;
- data o‘zgartirish;
- database metadata’sini olish;
- queryni buzish
maqsad qilinishi mumkin.
Asosiy himoya — prepared statement va bind parameter.
Command Injection
Application user inputini shell commandga qo‘shsa attacker qo‘shimcha command ishlatishga urinishi mumkin.
Masalan, file nomi yoki host argumenti xavfsiz ajratilmasa shell metacharacterlari talqin qilinadi.
Shell chaqirish o‘rniga argument array qabul qiluvchi API va allowlist ishlatiladi.
NoSQL Injection
Document database querysi ham user inputi bilan noto‘g‘ri qurilishi mumkin.
Input oddiy string deb kutilib, aslida query operatori yoki nested object bo‘lsa filter semantikasi o‘zgaradi.
Schema validation va typed query builder muhim.
Template Injection
Server-side template user matnini oddiy content emas, template code sifatida parse qilsa expression yoki function bajarilishi mumkin.
User yaratgan template alohida sandbox va cheklangan language talab qiladi.
Oddiy comment yoki ism template source’ga qo‘shilmaydi.
LDAP Injection
Directory query filterlari user inputi bilan concatenation qilinsa filter structure o‘zgarishi mumkin.
Escape qoidalari SQL’dan farq qiladi.
Har interpreter uchun o‘z parameter yoki encoding mexanizmi ishlatiladi.
Header Injection
HTTP header qiymatiga newline yoki control character kirsa qo‘shimcha header yoki response structure hosil bo‘lishi mumkin.
Framework odatda bunday characterlarni rad etadi.
Redirect, email header va log formatida ham newline injection xavfi mavjud.
Log Injection
User input logga to‘g‘ridan-to‘g‘ri yozilib, newline va soxta fieldlar orqali log recordlar qalbakilashtirilishi mumkin.
Structured logging va control character normalization ishlatiladi.
Log viewer HTML render qilsa output encoding ham zarur.
Parameterization
Parameterized queryda code va data alohida uzatiladi.
Driver inputni kerakli type sifatida encode qiladi.
Bu escapingni qo‘lda yozishdan ishonchliroq.
Table va column nomlari odatda bind parameter bo‘la olmaydi; ular allowlistdan tanlanadi.
Allowlist
Input mumkin bo‘lgan aniq qiymatlardan biriga mos bo‘lishi talab qilinadi.
Masalan:
sort = created_at | name | price
User bergan arbitrary SQL identifier ishlatilmaydi.
Allowlist ayniqsa command option, file format va dynamic operator uchun muhim.
Escaping cheklovi
Escaping interpreter contextiga bog‘liq.
SQL string escaping shell, HTML yoki JavaScript uchun yaroqli emas.
Encoding noto‘g‘ri qatlamda yoki ikki marta qo‘llansa muammo qoladi.
Imkon bo‘lsa code yaratishdan qochib, typed API ishlatiladi.
Input validation
Validation format, uzunlik, type va diapazonni tekshiradi.
Bu injectionga qarshi yordam beradi, ammo yagona himoya emas.
Masalan, ismda apostrof qonuniy bo‘lishi mumkin.
Parameterized query qonuniy characterlarni bloklamasdan xavfsizlik beradi.
Least privilege
Injection muvaffaqiyatli bo‘lsa ham database yoki process minimal huquqqa ega bo‘lishi zarar doirasini kamaytiradi.
Application account:
huquqlariga ega bo‘lmasligi kerak.
Error handling
Raw database yoki interpreter xatosi clientga chiqarilmaydi.
Bunday xato table nomi, query va pathni oshkor qilishi mumkin.
Ichki log correlation ID bilan saqlanadi, clientga umumiy xavfsiz javob qaytariladi.
Test
Security testlar:
- maxsus character;
- nested object;
- uzun input;
- invalid type;
- newline;
- template expression;
- dynamic identifier;
- second-order data
holatlarini tekshiradi.
Static analysis string concatenation va shell chaqiriqlarini topishga yordam beradi.
Second-order Injection
Zararli input avval database’da oddiy data sifatida saqlanadi.
Keyin boshqa jarayon uni query yoki command yaratishda ishlatganda injection yuz beradi.
Shuning uchun “data avval saqlangan, demak ishonchli” degan taxmin noto‘g‘ri.
ORM
ORM query yozishni soddalashtiradi, ammo raw expression, dynamic order, custom filter yoki raw SQL ishlatilsa injection qaytishi mumkin. ORM methodi parameter binding qiladimi, yo‘qmi hujjatdan tekshiriladi. User inputi method nomi yoki field sifatida bevosita uzatilmaydi.
Interpreter zanjiri
Bitta input bir nechta interpreterdan o‘tishi mumkin:
JSON → template → shell → SQL
Har qatlam o‘z contextiga mos data va code chegarasini saqlashi kerak. Birinchi qatlamdagi escaping keyingi interpreter uchun xavfsizlik bermaydi.
Code review
Review vaqtida sinklar qidiriladi: query, shell, template evaluation, dynamic import va header construction. Faqat input manbasini emas, data flow qayerda interpreterga kirishini aniqlash muhim. Taint analysis vositalari bunga yordam beradi.
Stored procedure
Stored procedure injectionni avtomatik bartaraf etmaydi. Procedure ichida dynamic SQL user inputi bilan concatenation qilinsa zaiflik saqlanadi. Parameterized procedure call va ichki bind parameter birgalikda ishlatiladi. Database permissioni faqat zarur procedure va table operationlari bilan cheklanadi.
Bog‘liq tushunchalar
SQL Injection, Command Injection, NoSQL Injection, Template Injection, Parameterized query, Input validation, Allowlist, Escaping, Least privilege, Interpreter