WisarWisar
Dasturlash kitobi/14-QISM — Xavfsizlik45 daqiqa

14.1-bob: Web xavfsizligi va OWASP Top 10

14-QISM — Web Xavfsizligi · 1-mavzu

1. Kirish va motivatsiya

Siz chiroyli, tez, funksional ilova qurishni o'rgandingiz (0-13 QISM). Lekin bitta savol qoldi: u xavfsizmi? Internetda har kun millionlab avtomatik hujum bo'ladi (botlar saytlarni tinmay sinab ko'radi), va bitta zaiflik (teshik) — barcha foydalanuvchi ma'lumoti o'g'irlanishi, hisoblar buzilishi, biznes obro'si yo'qolishi, hatto huquqiy javobgarlikka olib kelishi mumkin. Xavfsizlik — bu "qo'shimcha" emas, balki har professional ilovaning majburiy poydevori (chiroyli, lekin xavfsiz emas ilova — xavfli ilova). Bu QISM — ilovangizni hujumlardan himoya qilishni o'rgatadi.

Web xavfsizliginng "Injil"i — OWASP Top 10 (Open Worldwide Application Security Project — xavfsizlik bo'yicha jahon tashkiloti). Bu — eng keng tarqalgan va eng xavfli 10 ta zaiflik turini sanab, har birini qanday oldini olishni ko'rsatadigan ro'yxat (har necha yilda yangilanadi — eng so'nggi 2021). Bu — barcha xavfsizlik mutaxassislari va dasturchilar biladigan "alifbo" (ish suhbatida ham so'rashadi). Bu bob OWASP Top 10'ni umumiy ko'rib chiqadi (har biri keyingi boblarda chuqur), va xavfsizlik tafakkurini — "xavfsizlik dushman ko'zi bilan o'ylash" (hujumchi qanday o'ylaydi?) — shakllantiradi.

Bu bob: xavfsizlik nima va nega (tahdid modeli), OWASP Top 10 (har biri qisqacha), xavfsizlik tamoyillari (defense in depth, least privilege, fail securely), hujumchi tafakkuri (attacker mindset), hujum yuzasi (attack surface), xavfsizlik dasturlash hayot siklida (SDLC), va mas'uliyat (xavfsizlik — jamoaviy). Har mavzu to'liq, har misolda maqsad + izoh + tushuntirish bilan ochib beriladi.

O'xshatish: Web xavfsizligi — bu uy xavfsizligi. Siz chiroyli uy qurdingiz (ilova), lekin agar (1) eshik qulfsiz (autentifikatsiya yo'q), (2) deraza ochiq (validatsiya yo'q), (3) kalit gilam ostida (secret kodda), (4) signalizatsiya yo'q (monitoring yo'q) — har qancha chiroyli bo'lsa ham, o'g'ri kiradi. OWASP Top 10 — bu "uy o'g'irlashning eng keng 10 usuli" ro'yxati (eshikdan, derazadan, tomdan...) — har birini bilsangiz, mos himoya qo'yasiz (qulf, panjara, signalizatsiya). Hujumchi tafakkuri — "agar men o'g'ri bo'lganimda, bu uyga qanday kirardim?" (eng zaif joyni qidirish). Xavfsizlik — bir martalik emas (qulf qo'ydingiz — tamom emas), balki doimiy (yangi hujum usullari — yangi himoya). Va eng muhimi — bitta zaif joy yetarli (10 ta qulf, lekin bitta ochiq deraza — o'g'ri kiradi). Shuning uchun har qatlam himoyalanishi kerak.

Nega muhim?

  • Majburiy poydevor — xavfsizlik "qo'shimcha" emas (xavfsiz bo'lmagan ilova — vaqt masalasi, buziladi).
  • Katta zarar — bitta zaiflik = ma'lumot o'g'irlanishi, obro', pul, huquqiy javobgarlik.
  • Avtomatik hujumlar — botlar tinmay sinaydi (siz mashhur bo'lmasangiz ham — avtomatik).
  • Professional talab — xavfsizlik — har dasturchining majburiy ko'nikmasi (ish suhbatida so'rashadi).

2. Nazariya — chuqur tushuntirish

2.1. Xavfsizlik nima va tahdid modeli

text
  XAVFSIZLIK — ma'lumot va tizimni himoyalash (3 asosiy xususiyat — CIA):

  C — CONFIDENTIALITY (maxfiylik): faqat ruxsatli odam ko'radi (parol, shaxsiy ma'lumot)
  I — INTEGRITY (yaxlitlik): ma'lumot o'zgartirilmasin (kim balansini o'zgartirmasin)
  A — AVAILABILITY (mavjudlik): tizim ishlayversin (DoS hujum — ishdan chiqarish)

  TAHDID MODELI (threat model — kimdan, nimani himoya):
  1. NIMANI himoya qilamiz? (ma'lumot — parol, to'lov, shaxsiy)
  2. KIMDAN? (hujumchi — bot, raqobatchi, ichki xodim)
  3. QANDAY hujum? (XSS, injection, o'g'irlik — OWASP)
  4. QANDAY himoya? (har tahdidga mos himoya)

   Xavfsizlik — CIA (maxfiylik + yaxlitlik + mavjudlik) — uchalasini himoyalash
   Tahdid modeli — nimani, kimdan, qanday, qanday himoya (oldindan o'ylash)

Xavfsizlik nima va tahdid modeli — xavfsizlik tafakkurining asosi. Xavfsizlik — ma'lumot va tizimni himoyalash, va uning uch asosiy xususiyati bor (CIA triad): (1) Confidentiality (maxfiylik) — ma'lumotni faqat ruxsatli odam ko'radi (parol, to'lov, shaxsiy ma'lumot — begona ko'rmasin); (2) Integrity (yaxlitlik) — ma'lumot ruxsatsiz o'zgartirilmasin (masalan kimdir o'z bank balansini o'zgartirmasin, narxni o'zgartirmasin); (3) Availability (mavjudlik) — tizim ishlab tursin (DoS hujum — serverni ishdan chiqarish — foydalanuvchilar kira olmay qoladi). Tahdid modeli (threat model — xavfsizlik rejasi): (1) nimani himoya qilamiz? (qaysi ma'lumot qimmatli — parol, to'lov, shaxsiy); (2) kimdan? (hujumchi — avtomatik bot, raqobatchi, norozi xodim, davlat); (3) qanday hujum? (XSS, injection, o'g'irlik — OWASP — 2.2); (4) qanday himoya? (har tahdidga mos). Ikki nuqta: (1) xavfsizlik — CIA (maxfiylik + yaxlitlik + mavjudlik — uchalasini himoyalash); (2) tahdid modeli — nimani, kimdan, qanday, qanday himoya (oldindan o'ylash — kod yozishdan oldin "bu qanday buzilishi mumkin?"). Bu — xavfsizlik tafakkuri (faqat "ishlasin" emas, balki "xavfsiz ishlasin"). Har funksiya yozganda: "bu qanday suiiste'mol qilinishi mumkin?" (hujumchi ko'zi bilan — 2.4). CIA va tahdid modeli — xavfsizlikni tizimli o'ylashning asosi (tasodifiy emas — rejali).

2.2. OWASP Top 10 (umumiy ko'rinish)

text
  OWASP TOP 10 (2021) — eng keng 10 xavfsizlik zaifligi:

  A01 — Broken Access Control (buzuq ruxsat nazorati):
       foydalanuvchi ruxsatsiz narsaga kira oladi (admin sahifa, boshqa hisob — 13.9: 2.9)
  A02 — Cryptographic Failures (shifrlash xatolari):
       ma'lumot shifrlanmagan (ochiq parol, HTTP — 14.5, 14.7)
  A03 — Injection (in'ektsiya — SQL, NoSQL, command):
       yomon ma'lumot kod sifatida bajariladi 14.3-bob
  A04 — Insecure Design (xavfsiz emas dizayn):
       arxitektura darajasida zaiflik (xavfsizlik o'ylanmagan)
  A05 — Security Misconfiguration (noto'g'ri sozlash):
       default parol, ochiq port, keraksiz xizmat 14.7-bob
  A06 — Vulnerable Components (zaif komponentlar):
       eski/zaif kutubxonalar (npm audit — 14.9)
  A07 — Authentication Failures (autentifikatsiya xatolari):
       zaif parol, sessiya o'g'irlik 14.5-bob
  A08 — Data Integrity Failures (ma'lumot yaxlitligi):
       ishonchsiz manba (deserializatsiya, CI/CD)
  A09 — Logging Failures (log/monitoring yo'q):
       hujum sezilmaydi (13.10 monitoring)
  A10 — SSRF (Server-Side Request Forgery):
       server'ni yomon so'rovga majburlash (14.4)

   OWASP Top 10 — eng keng zaifliklar (A01-A10); har biri keyingi boblarda chuqur
   A01 (ruxsat) va A03 (injection) — eng keng; hammasini bilish kerak

OWASP Top 10 (umumiy ko'rinish) — web xavfsizligining asosiy ro'yxati. OWASP Top 10 (2021 versiyasi) — eng keng tarqalgan, eng xavfli 10 zaiflik: A01 — Broken Access Control (buzuq ruxsat — foydalanuvchi ruxsatsiz narsaga kira oladi — admin sahifa, boshqa odam hisobi — eng keng — 13.9: 2.9); A02 — Cryptographic Failures (shifrlash xatolari — ochiq parol, HTTP — 14.5, 14.7); A03 — Injection (yomon ma'lumot kod sifatida bajariladi — SQL, NoSQL, command — 14.3); A04 — Insecure Design (dizayn darajasida zaiflik — xavfsizlik o'ylanmagan); A05 — Security Misconfiguration (noto'g'ri sozlash — default parol, ochiq port — 14.7); A06 — Vulnerable Components (eski/zaif kutubxonalar — npm audit — 14.9); A07 — Authentication Failures (zaif parol, sessiya o'g'irlik — 14.5); A08 — Data Integrity Failures (ishonchsiz manba — deserializatsiya, CI/CD); A09 — Logging Failures (log/monitoring yo'q — hujum sezilmaydi — 13.10); A10 — SSRF (server'ni yomon so'rovga majburlash — 14.4). Ikki nuqta: (1) OWASP Top 10 — eng keng zaifliklar (A01-A10), har biri keyingi boblarda chuqur ochiladi (XSS, injection, CSRF, auth, headers); (2) A01 (ruxsat nazorati) va A03 (injection) — eng keng uchraydigan (lekin hammasini bilish kerak — bitta zaiflik yetarli — 2.4). Bu ro'yxat — xavfsizlik dasturchining "tekshiruv ro'yxati" (har ilovada: A01-A10 — qaysi zaiflik bormi?). OWASP Top 10 — xavfsizlik bilimining poydevori (har dasturchi bilishi shart — ish suhbatida so'rashadi). Diqqat: bu statik kod xavfsizligi haqida emas, balki ilova darajasida (qanday ishlaydi — qaysi teshik bor). Har bobda (14.2-14.8) bu zaifliklar chuqur (hujum + himoya).

2.3. Xavfsizlik tamoyillari

text
  XAVFSIZLIK TAMOYILLARI — asosiy qoidalar (har himoya shularga asoslanadi):

  1. DEFENSE IN DEPTH (chuqur himoya — qatlamlar):
   bitta himoyaga ishonma; ko'p qatlam (UI + server + DB — biri buzilsa, keyingi)
   13.9: 2.9 (middleware + sahifa + Server Action)

  2. LEAST PRIVILEGE (eng kam imtiyoz):
   har kim/narsaga FAQAT kerakli ruxsat (admin emas — default oddiy)
   DB foydalanuvchi faqat kerakli jadvalga (butun DB emas)

  3. FAIL SECURELY (xavfsiz yiqil):
   xato bo'lsa — XAVFSIZ holatga (ruxsat BERMA, ma'lumot YASHIR)
   xato bo'lsa "ruxsat ber" emas, "rad et" (default deny)

  4. NEVER TRUST USER INPUT (foydalanuvchi ma'lumotiga ishonma):
   har kirish ma'lumot — POTENSIAL hujum (validatsiya, sanitizatsiya — 14.2, 14.3)

  5. KEEP IT SIMPLE (sodda tut):
   murakkab kod — ko'proq teshik; sodda — kam xato

   Tamoyillar: defense in depth, least privilege, fail securely, never trust input, simple
   Har himoya shularga asoslanadi (qoida — texnika emas; har holatda qo'llaniladi)

Xavfsizlik tamoyillari — har himoyaning asosidagi qoidalar. Besh asosiy tamoyil: (1) Defense in depth (chuqur himoya — qatlamlar): bitta himoyaga ishonma, ko'p qatlam qo'y (UI + server + DB — biri buzilsa, keyingisi ushlaydi — 13.9: 2.9 — middleware + sahifa + Server Action — eng muhim tamoyil); (2) Least privilege (eng kam imtiyoz): har kim/narsaga faqat kerakli ruxsat (default — minimal; admin emas — oddiy; DB foydalanuvchi faqat kerakli jadvalga — butun DB emas — agar buzilsa, zarar cheklangan); (3) Fail securely (xavfsiz yiqil): xato bo'lganda xavfsiz holatga o't (ruxsat berma, ma'lumot yashir — "default deny" — masalan auth tekshiruvi xato bersa, "ruxsat ber" emas "rad et"); (4) Never trust user input (foydalanuvchi ma'lumotiga ishonma): har kirish ma'lumot — potensial hujum (validatsiya, sanitizatsiya — 14.2, 14.3 — foydalanuvchi kiritgan hamma narsani tekshir); (5) Keep it simple (sodda tut): murakkab kod — ko'proq teshik, sodda — kam xato (murakkablik — xavfsizlik dushmani). Ikki nuqta: (1) tamoyillar — defense in depth, least privilege, fail securely, never trust input, keep simple (har biri keng qo'llaniladi); (2) har himoya shu tamoyillarga asoslanadi (bular — qoida, aniq texnika emas — har holatda qo'llaniladi — masalan "never trust input" validatsiya, sanitizatsiya, parametrlangan so'rov — hammasi shu tamoyildan). Bu tamoyillar — xavfsizlik tafakkurining "kompasi" (har qaror — bu tamoyillarga mos kelishi kerak). Eng muhimi — defense in depth (bir qatlamga ishonma) va never trust input (har kirish — potensial hujum). Bu tamoyillarni o'zlashtirish — har xavfsizlik masalasini to'g'ri hal qilishning asosi.

2.4. Hujumchi tafakkuri (attacker mindset)

text
  HUJUMCHI TAFAKKURI — "agar men hujumchi bo'lganimda?" (zaiflikni topish):

  DASTURCHI o'ylaydi: "bu qanday ISHLAYDI?" (happy path — to'g'ri foydalanish)
  HUJUMCHI o'ylaydi: "bu qanday BUZILADI?" (zaiflik — noto'g'ri foydalanish)

  HUJUMCHI SAVOLLARI (har funksiyaga):
   "Agar bu maydonga kod kiritsam?" (XSS, injection — 14.2, 14.3)
   "Agar boshqa odamning ID'sini so'rasam?" (broken access — A01)
   "Agar URL'ni o'zgartirsam?" (/admin'ga to'g'ridan)
   "Agar so'rovni qaytarib yuborsam?" (replay, CSRF — 14.4)
   "Agar 1 million so'rov yuborsam?" (DoS, brute force — 14.8)

  HIMOYA: har funksiyani hujumchi ko'zi bilan ko'r (qanday suiiste'mol?)

  ┌────────────────────────────────────────────────────────────┐
  │ Dasturchi: "ishlaydimi?" | Hujumchi: "buziladimi?"          │
  │  xavfsizlik = ikkala ko'z (qurish + buzishga urinish)      │
  └────────────────────────────────────────────────────────────┘

   Hujumchi tafakkuri — "qanday buziladi?" (happy path emas — suiiste'mol yo'llari)
   Har funksiyani hujumchi ko'zi bilan ko'r (kiritish, ID, URL, takror, ko'plik)

Hujumchi tafakkuri (attacker mindset) — xavfsizlikni ko'rishning kaliti. Xavfsizlik — bu ikki ko'z bilan ko'rish: dasturchi ko'zi ("bu qanday ishlaydi?" — happy path — to'g'ri foydalanish) va hujumchi ko'zi ("bu qanday buziladi?" — zaiflik — noto'g'ri/yomon foydalanish). Ko'p dasturchi faqat birinchi ko'z bilan qaraydi (ishlasin — tamom), lekin xavfsizlik — ikkinchi ko'zni talab qiladi. Hujumchi savollari (har funksiyaga beriladigan): (1) "Agar bu maydonga kod kiritsam?" (XSS, injection — 14.2, 14.3 — input'ga <script> yoki SQL); (2) "Agar boshqa odamning ID'sini so'rasam?" (/api/users/123 o'rniga 124 — broken access — A01); (3) "Agar URL'ni o'zgartirsam?" (/adminga to'g'ridan kirsam — ruxsat tekshiriladimi?); (4) "Agar so'rovni qaytarib yuborsam?" (replay, CSRF — 14.4); (5) "Agar 1 million so'rov yuborsam?" (DoS, parol brute force — 14.8). Ikki nuqta: (1) hujumchi tafakkuri — "qanday buziladi?" (happy path emas — suiiste'mol yo'llarini izlash); (2) har funksiyani hujumchi ko'zi bilan ko'r (kiritish — kod?, ID — boshqaniki?, URL — to'g'ridan?, takror — replay?, ko'plik — DoS?). Bu — xavfsizlik tafakkurining yuragi (kod yozganda ikkala ko'z — qurish + buzishga urinish). Professional dasturchi o'z kodini "buzishga" urinadi (qanday suiiste'mol qilinishi mumkin?), keyin himoya qo'yadi. Bu ko'nikma — amaliyot bilan rivojlanadi (har funksiyaga "buziladimi?" savolini berish odati). CTF (Capture The Flag — xavfsizlik musobaqalari), bug bounty (zaiflik topib mukofot) — bu tafakkurni o'rgatadi. Hujumchi tafakkuri — himoyaning birinchi qadami (dushmanni tushunmasdan himoyalab bo'lmaydi).

2.5. Hujum yuzasi va xavfsizlik hayot siklida

text
  HUJUM YUZASI (attack surface) — hujum mumkin bo'lgan barcha nuqta:

   har KIRISH nuqtasi potensial hujum (forma, URL, API, header, cookie, fayl yuklash)
   KAM hujum yuzasi = xavfsizroq (keraksiz endpoint/xususiyat — o'chir)

  HUJUM YUZASINI KAMAYTIRISH:
   Keraksiz endpoint/xususiyatni o'chir (ishlatilmasa — yo'q)
   Keraksiz ma'lumot bermaslik (faqat kerakli — over-fetching emas)
   Default sozlamalarni o'zgartir (default parol/port — A05)

  XAVFSIZLIK HAYOT SIKLIDA (SDLC — har bosqichda):
  Dizayn (threat model)  Kod (xavfsiz yozish)  Test (xavfsizlik testi) 
  Deploy (xavfsiz sozlash)  Monitoring (hujum kuzatuvi)
   xavfsizlik OXIRIDA emas, HAR bosqichda (shift left)

   Hujum yuzasi — barcha kirish nuqtasi (kam = xavfsizroq; keraksizni o'chir)
   Xavfsizlik har bosqichda (dizaynkodtestdeploymonitoring) — oxirida emas

Hujum yuzasi va xavfsizlik hayot siklida — xavfsizlikni tizimli yondashuv. Hujum yuzasi (attack surface) — hujum mumkin bo'lgan barcha nuqta (har kirish nuqtasi — forma, URL, API endpoint, header, cookie, fayl yuklash, query parametr — potensial hujum joyi). Qoida: kam hujum yuzasi = xavfsizroq (qancha kam kirish nuqtasi — shuncha kam buzilish imkoni). Hujum yuzasini kamaytirish: (1) keraksiz endpoint/xususiyatni o'chir (ishlatilmaydigan API, eski sahifa — yo'q qil — ular ham hujum nuqtasi); (2) keraksiz ma'lumot bermaslik (faqat kerakli — masalan API foydalanuvchi parolini qaytarmasin — over-fetching xavfli); (3) default sozlamalarni o'zgartirish (default parol/port — A05 — Security Misconfiguration). Xavfsizlik hayot siklida (SDLC — Software Development Life Cycle): xavfsizlik har bosqichda — dizayn (threat model — 2.1), kod (xavfsiz yozish — validatsiya), test (xavfsizlik testi), deploy (xavfsiz sozlash — 13.10), monitoring (hujum kuzatuvi — 13.10). Bu "shift left" (xavfsizlikni jarayonning boshiga surish — oxirida emas — chunki oxirida topilgan zaiflik tuzatish qimmat). Ikki nuqta: (1) hujum yuzasi — barcha kirish nuqtasi (kam = xavfsizroq — keraksizni o'chir, faqat keraklisini qoldir); (2) xavfsizlik har bosqichda (dizayn kod test deploy monitoring — oxirida "endi xavfsizlik qo'shamiz" emas, balki boshidan). Bu — xavfsizlikni jarayonning qismi sifatida ko'rish (alohida "xavfsizlik bosqichi" emas — har qadamda). Professional jamoalarda xavfsizlik har bosqichda (dizaynda — threat model, kodda — review, test — penetration test, deploy — config, ishlab turishda — monitoring). Hujum yuzasini kichik tutish va xavfsizlikni erta o'ylash — proaktiv himoya (reaktiv — buzilgandan keyin tuzatish — qimmat, kech).

2.6. OWASP nima, zero trust va mas'uliyat taqsimoti

text
  OWASP (Open Worldwide Application Security Project) — nokommersiya tashkilot:
   bepul, ochiq xavfsizlik bilimi (Top 10 — eng mashhuri, lekin bir qismi)
   Top 10: eng keng 10 zaiflik (awareness — xabardorlik ro'yxati)
   ASVS (Application Security Verification Standard): batafsil tekshiruv standarti
     (3 daraja: L1 oddiy, L2 sezgir ma'lumot, L3 kritik — bank/tibbiyot)
   Cheat Sheet Series: har mavzuga amaliy "qanday to'g'ri qilish" qo'llanmasi

  ZERO TRUST ("hech kimga ishonma, har doim tekshir"):
   eski model: "ichki tarmoq ishonchli, tashqi — xavfli" (qal'a-xandaq)
   zero trust: har so'rov tekshiriladi (ichkarida ham — ichki tarmoq ham buzilishi mumkin)
   "never trust, always verify" — 2.3 (never trust input)ning kengaytmasi

  MAS'ULIYAT TAQSIMOTI (frontend vs backend):
  FRONTEND (brauzerda — foydalanuvchi ko'radi/o'zgartiradi mumkin):
     UX, tezkor validatsiya (qulaylik) — LEKIN HIMOYA EMAS (aylanib o'tiladi)
  BACKEND (serverda — foydalanuvchi ko'ra/o'zgartira olmaydi):
     HAQIQIY himoya: auth, ruxsat, validatsiya, biznes qoida (majburiy)

   Frontend — hech qachon yagona himoya emas (server — haqiqiy chegara)
   Zero trust — har so'rov tekshiriladi (ichki/tashqi farq qilmaydi)

OWASP nima, zero trust va mas'uliyat taqsimoti — kontekst va zamonaviy model. OWASP (Open Worldwide Application Security Project) — bu bir "ro'yxat" emas, balki nokommersiya tashkilot — u web xavfsizligi bo'yicha bepul, ochiq bilim ishlab chiqaradi. Top 10 — eng mashhur mahsuloti (xabardorlik — awareness — ro'yxati), lekin faqat bir qismi. Boshqa muhim resurslar: (1) ASVS (Application Security Verification Standard) — ilovani chuqur tekshirish uchun batafsil standart (uch daraja: L1 — oddiy ilova, L2 — sezgir ma'lumot bilan, L3 — kritik: bank, tibbiyot); (2) Cheat Sheet Series — har aniq mavzuga (parol saqlash, XSS, JWT, ...) "qanday to'g'ri qilish" amaliy qo'llanmasi (dasturchi uchun eng foydali). Zero trust — zamonaviy xavfsizlik modeli: eski model "ichki tarmoq ishonchli, tashqi — xavfli" deb hisoblardi (qal'a va uni o'rab olgan xandaq — bir marta ichkariga kirsangiz, erkin), lekin zamonaviy tahdidlar (ichki xodim, buzilgan ichki xizmat) buni yaroqsiz qildi. Zero trust — "hech kimga ishonma, har doim tekshir" (never trust, always verify): har so'rov, hatto ichki tarmoqdan kelsa ham, autentifikatsiya va avtorizatsiyadan o'tadi (bu — 2.3 "never trust input" tamoyilining butun arxitekturaga kengaytmasi). Mas'uliyat taqsimoti (frontend vs backend — juda muhim): frontend (brauzerda ishlaydi — foydalanuvchi uni ko'radi va o'zgartira oladi — DevTools, so'rovni qo'lda yuborish) — bu yerda validatsiya faqat UX uchun (tez fikr-mulohaza, qulaylik), himoya emas (oson aylanib o'tiladi — Misol 4); backend (serverda — foydalanuvchi kira/o'zgartira olmaydi) — bu yerda haqiqiy himoya (auth, ruxsat, validatsiya, biznes qoidalari — majburiy). Ikki nuqta: (1) frontend — hech qachon yagona himoya bo'la olmaydi (server — haqiqiy xavfsizlik chegarasi — barcha muhim tekshiruv serverda takrorlanishi shart); (2) zero trust — har so'rov tekshiriladi (ichki/tashqi farqi yo'q — "ichkarida ekan, demak ishonchli" — xavfli taxmin). Bu tushunchalar — xavfsizlik tafakkurining zamonaviy asosi: OWASP resurslaridan foydalaning (Cheat Sheet — amaliy javob), zero trust bilan o'ylang (har chegarada tekshir), va himoyani doim serverda quring (frontend — yordamchi, server — hakam).

3. Sintaksis — OWASP Top 10 tez ma'lumotnoma

text
A01 Access Control:  ruxsat tekshir har joyda (13.9: 2.9 — middleware+server+action)
A02 Cryptographic:   parol hash (bcrypt), HTTPS, ma'lumot shifrlash (14.5, 14.7)
A03 Injection:       parametrlangan so'rov, validatsiya, sanitizatsiya 14.3-bob
A04 Insecure Design: threat model, xavfsiz arxitektura 2.1-bob
A05 Misconfiguration:default o'zgartir, keraksizni o'chir (2.5, 14.7)
A06 Components:       npm audit, yangilab tur 14.9-bob
A07 Auth Failures:   kuchli parol, sessiya xavfsizligi, rate limit (14.5, 14.8)
A08 Integrity:        ishonchli manba, imzo tekshir (webhook — 13.6)
A09 Logging:          log + monitoring (Sentry — 13.10)
A10 SSRF:             tashqi URL validatsiya (14.4)

4. Batafsil misollar

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

Misol 1 — Broken Access Control (A01 — eng keng)

Maqsad: Eng keng zaiflik — broken access control — qanday yuzaga kelishini va himoyasini ko'rsatish. Bu OWASP'ning 1-o'rni (eng ko'p uchraydi).

tsx
//  ZAIF — foydalanuvchi boshqa odamning ma'lumotini ko'radi (IDOR):
export async function GET(req: Request, { params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  // Faqat ID bilan oladi — KIM so'rayotgani tekshirilmaydi!
  const order = await db.order.findUnique({ where: { id } });
  return Response.json(order);   // /api/orders/123  boshqa odamning buyurtmasi!
}
//  hujumchi /api/orders/124, 125... — HAMMA buyurtmani ko'radi (IDOR — A01)

//  XAVFSIZ — egalik tekshiriladi:
export async function GET(req: Request, { params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const session = await auth();
  if (!session) return Response.json({ error: "Kiring" }, { status: 401 });

  const order = await db.order.findUnique({ where: { id } });
  //  EGALIK tekshir — bu buyurtma shu foydalanuvchiniki emasmi?
  if (!order || order.userId !== session.user.id) {
    return Response.json({ error: "Topilmadi" }, { status: 404 });   // o'ziniki emas
  }
  return Response.json(order);
}

Bu nima qiladi: Bu — Broken Access Control (A01 — OWASP 1-o'rni — eng keng zaiflik). Zaif kod: /api/orders/[id] faqat ID bilan buyurtmani oladi — kim so'rayotgani tekshirilmaydi. Bu IDOR (Insecure Direct Object Reference — to'g'ridan obyekt havolasi zaifligi): hujumchi o'z buyurtmasini ko'rib (/api/orders/123), keyin ID'ni o'zgartirib (/api/orders/124, 125...) — boshqa odamlarning buyurtmalarini ko'radi (ism, manzil, to'lov — barcha shaxsiy ma'lumot sizib ketadi). Bu juda keng xato (ko'p sayt buni qiladi — ID bilan oladi, egalik tekshirmaydi). Xavfsiz kod: (1) autentifikatsiya (session — kim?), (2) egalik tekshir (order.userId !== session.user.id — bu buyurtma shu foydalanuvchiniki emasmi?), agar o'ziniki emas — 404 (topilmadi — 403dan yaxshiroq — buyurtma borligini ham oshkor qilmaslik). Endi hujumchi boshqa ID so'rasa — 404 (o'ziniki emas — ko'ra olmaydi). Tamoyil 2.3-bob: never trust user input (ID — foydalanuvchi beradi — ishonma, egalik tekshir). Bu A01 — eng keng, eng oson e'tibordan chetda qoladigan zaiflik (autentifikatsiya bor, lekin avtorizatsiya — egalik — yo'q). Qoida: har resurs so'rovida "bu foydalanuvchi bu resursga ega/ruxsatli?" tekshir (13.9: 2.9). Faqat login yetarli emas — kim nimani ko'ra oladi (egalik/rol) — har joyda.

Misol 2 — Injection tahlili (A03)

Maqsad: Injection hujumining mohiyatini ko'rsatish — yomon ma'lumot kod sifatida bajarilishi. Bu 14.3'da chuqur, bu yerda asosiy g'oya.

tsx
//  ZAIF — SQL injection (foydalanuvchi ma'lumoti so'rovga to'g'ridan):
const email = req.body.email;   // foydalanuvchi: ' OR '1'='1
const query = `SELECT * FROM users WHERE email = '${email}'`;
//  SELECT * FROM users WHERE email = '' OR '1'='1'  (HAMMA foydalanuvchi!)
// db.raw(query) — hujumchi butun jadvalni oladi (yoki o'chiradi)

//  XAVFSIZ — parametrlangan so'rov (ma'lumot KOD emas, MA'LUMOT):
const users = await db.user.findMany({ where: { email } });   // Prisma — xavfsiz (parametrlangan)
// yoki raw SQL bilan: db.$queryRaw`SELECT * FROM users WHERE email = ${email}`  (parametrlangan)
//  email FAQAT qiymat sifatida (kod sifatida emas — injection yo'q)

// MOHIYAT: foydalanuvchi ma'lumoti KOD bilan ARALASHMACligi kerak
//  string birlashtirish (${}) — XAVFLI; parametrlangan — XAVFSIZ

Bu nima qiladi: Bu — Injection (A03 — OWASP 3-o'rni) mohiyati. Zaif kod: foydalanuvchi email'ini SQL so'roviga string birlashtirish bilan (${email}) qo'shadi. Hujumchi email o'rniga ' OR '1'='1 kiritsa, so'rov SELECT * FROM users WHERE email = '' OR '1'='1' bo'ladi — '1'='1' doimo rost — so'rov barcha foydalanuvchini qaytaradi (yoki '; DROP TABLE users; -- bilan jadvalni o'chiradi). Bu — SQL injection (yomon ma'lumot kod sifatida bajariladi). Xavfsiz kod: parametrlangan so'rov (Prisma findMany({ where: { email } }), yoki raw SQL'da $queryRaw\... ${email}`— Prisma teglangan shablon) — bu yerdaemail**faqat qiymat** sifatida ishlatiladi (kod sifatida emas — DB uni "qidiriladigan matn" deb biladi, "bajariladigan buyruq" emas). Hujumchi' OR '1'='1 kiritsa ham — u **butun** email sifatida qidiriladi (bunday email yo'q — natija bo'sh — injection ishlamaydi). **Mohiyat**: foydalanuvchi ma'lumoti **kod bilan aralashmasligi** kerak — string birlashtirish (${}`) aralashtiradi (xavfli — ma'lumot kodga aylanadi), parametrlangan so'rov ajratadi (xavfsiz — ma'lumot ma'lumot bo'lib qoladi). Bu injection'ning (SQL, NoSQL, command, LDAP — har turi) umumiy tamoyili (14.3'da chuqur). Tamoyil 2.3-bob: never trust user input. Zamonaviy ORM (Prisma — 6.12) default parametrlangan (xavfsiz), lekin raw SQL yoki string birlashtirish — xavfli. Qoida: foydalanuvchi ma'lumotini hech qachon kodga (SQL, HTML, shell) to'g'ridan qo'shma — parametrlangan/sanitizatsiya.

Misol 3 — Tahdid modeli amalda (2.1)

Maqsad: Real funksiya uchun threat model qilish — nimani, kimdan, qanday himoya. Bu xavfsizlikni tizimli o'ylashning amaliy namunasi.

text
FUNKSIYA: "Foydalanuvchi parolni tiklaydi" (forgot password)

THREAT MODEL:
1. NIMANI himoya?  foydalanuvchi hisobi (parol tiklash orqali egallab olinmasin)

2. KIMDAN?  hujumchi (boshqa odamning hisobini egallashga urinadi)

3. QANDAY hujum?
    "Boshqa email kiritsam — uning parolini tiklaymanmi?" (ha, lekin link EGASIGA boradi — OK)
    "Tiklash linkini taxmin qila olamanmi?" (token zaif bo'lsa — ha — XAVF)
    "Link cheksiz ishlaydimi?" (muddatsiz — eski link o'g'irlansa — XAVF)
    "1000 marta urinsam?" (brute force token — XAVF)
    "Tiklash sahifasi email mavjudligini oshkor qiladimi?" ("email yo'q" — ma'lumot sizishi)

4. QANDAY himoya?
    Kuchli tasodifiy token (taxmin qilib bo'lmaydigan — crypto)
    Token muddati (15-30 daqiqa — keyin ishlamaydi)
    Bir martalik token (ishlatilgach — bekor)
    Rate limiting (ko'p urinish — bloklash — 14.8)
    Bir xil javob (email bor/yo'qligini oshkor qilma)

Bu nima qiladi: Bu — tahdid modeli amalda (2.1 — xavfsizlikni tizimli o'ylash). "Parolni tiklash" (forgot password) — keng, lekin xavfli funksiya (noto'g'ri qilinsa — hisob egallash usuli). Threat model (4 savol): (1) nimani — foydalanuvchi hisobi (parol tiklash orqali egallab olinmasin); (2) kimdan — hujumchi (boshqa odamning hisobini egallashga urinadi); (3) qanday hujum — har imkoniyatni hujumchi ko'zi bilan 2.4-bob: boshqa email kiritsa (link egasiga boradi — OK), tiklash linkini taxmin qila oladimi (token zaif bo'lsa — xavf), link cheksiz ishlaydimi (muddatsiz — eski link o'g'irlansa — xavf), 1000 marta urinsa (token brute force — xavf), sahifa email mavjudligini oshkor qiladimi ("bu email ro'yxatda yo'q" — hujumchiga qaysi email bor/yo'qligini aytadi — ma'lumot sizishi); (4) qanday himoya — har xavfga mos: kuchli tasodifiy token (crypto — taxmin qilib bo'lmaydi), token muddati (15-30 daqiqa), bir martalik (ishlatilgach bekor), rate limiting (ko'p urinish — bloklash — 14.8), bir xil javob (email bor/yo'qligini oshkor qilma — "agar email mavjud bo'lsa, link yuborildi"). Bu — threat model amaliyoti: bir funksiyani olib, uni hujumchi ko'zi bilan tahlil qilish (qanday buziladi?), keyin har xavfga himoya. Bu — xavfsiz kod yozishning usuli (kod yozishdan oldin "bu qanday hujum qilinishi mumkin?" — har funksiyaga). Parol tiklash — klassik misol (ko'p sayt buni noto'g'ri qiladi — zaif token, muddatsiz, email oshkor). Threat model — xavfsizlikni rejali qiladi (tasodifiy "xavfsizlik qo'shamiz" emas — har xavfni aniqlab, himoya). Har muhim funksiyaga (login, to'lov, parol tiklash, ma'lumot o'zgartirish) threat model qilish — professional yondashuv.

Misol 4 — Defense in depth amalda (2.3)

Maqsad: Bir himoyaga ishonmaslik — ko'p qatlam himoya. Bu eng muhim tamoyil (bitta qatlam buzilsa, keyingisi ushlaydi).

tsx
// MUAMMO: admin mahsulot o'chiradi — qancha himoya qatlami kerak?

// QATLAM 1 — UI (admin emasga tugma ko'rsatma — UX, lekin HIMOYA EMAS):
{session?.user.role === "admin" && <DeleteButton />}

// QATLAM 2 — Middleware (/admin yo'liga — markaziy — 13.6):
if (path.startsWith("/admin") && session?.user.role !== "admin") redirect("/");

// QATLAM 3 — Server Action (HAQIQIY himoya — ochiq endpoint — 13.5: 2.11):
"use server";
export async function deleteProduct(id: string) {
  const session = await auth();
  if (session?.user.role !== "admin") throw new Error("Ruxsat yo'q");   //  majburiy
  await db.product.delete({ where: { id } });
}

// QATLAM 4 — DB ruxsat (least privilege — app foydalanuvchi faqat kerakli):
// DB'da app faqat kerakli operatsiyaga ruxsatli

//  HAR qatlam mustaqil — biri aylanib o'tilca (UI yashirilgan, lekin so'rov to'g'ridan),
//    keyingisi (Server Action) ushlaydi — DEFENSE IN DEPTH

Bu nima qiladi: Bu — defense in depth (chuqur himoya — eng muhim tamoyil — 2.3). "Admin mahsulot o'chiradi" amali uchun to'rt himoya qatlami: (1) UI — admin emasga "O'chirish" tugmasini ko'rsatma (role === "admin" && <DeleteButton />) — bu UX (oddiy foydalanuvchi tugmani ko'rmaydi), lekin himoya emas (tugma yashirilgan, lekin so'rov to'g'ridan yuborilsa?); (2) middleware — /admin yo'liga admin emas kirsa, redirect (markaziy — 13.6 — birinchi to'siq); (3) Server Action — haqiqiy himoya: if (session?.user.role !== "admin") throw (ochiq endpoint — 13.5: 2.11 — kim chaqirsa ham, rol tekshiriladi — bu majburiy); (4) DB ruxsat — least privilege (app DB foydalanuvchi faqat kerakli operatsiyaga — agar app buzilsa, zarar cheklangan). Eng muhim g'oya: har qatlam mustaqil — agar biri aylanib o'tilsa (masalan hujumchi UI'ni chetlab, so'rovni to'g'ridan Server Action'ga yuborsa — UI yashirish foydasiz), keyingi qatlam (Server Action'ning rol tekshiruvi) uni ushlaydi. Bu — defense in depth: bitta himoyaga ishonma (UI yashirish — yagona himoya bo'lsa, oson aylanib o'tiladi), ko'p qatlam (UI + middleware + Server Action + DB — biri buzilsa, keyingisi). Eng keng xato — faqat UI'da himoya (tugmani yashirish) — bu xavfsizlik emas (so'rovni to'g'ridan yuborsa — ochiq). Haqiqiy himoya — server'da (Server Action/API — kim chaqirsa ham tekshir). UI — UX uchun (qulay), server — xavfsizlik uchun (majburiy). Bu tamoyil — 13.9: 2.9'da auth kontekstida ko'rdik, bu yerda umumiy (har himoya ko'p qatlam). Defense in depth — xavfsizlikning poydevori (bir teshik — boshqa qatlam ushlaydi).

Misol 5 — Xavfsizlik audit ro'yxati (2.2, 2.5)

Maqsad: Ilovani OWASP Top 10 bo'yicha tekshirish ro'yxati — har zaiflik bormi. Bu xavfsizlik auditining amaliy boshlanishi.

text
ILOVA XAVFSIZLIK AUDITI (OWASP Top 10 — har birini tekshir):

A01 ACCESS CONTROL:
  [ ] Har resurs so'rovida egalik/rol tekshiriladimi? (IDOR — Misol 1)
  [ ] Server Action/API — UI'dan tashqari ham himoyalanganmi? (Misol 4)

A02 CRYPTOGRAPHIC:
  [ ] Parol bcrypt bilan hashlanganmi? (ochiq emas — 14.5)
  [ ] HTTPS majburiymi? (HTTP yo'q — 14.7)
  [ ] Secret env'dami? (kodda emas — 13.10)

A03 INJECTION:
  [ ] DB so'rovlar parametrlanganmi? (string birlashtirish yo'q — Misol 2, 14.3)
  [ ] Foydalanuvchi kiritishi validatsiya/sanitizatsiya qilinadimi? 14.2-bob

A05 MISCONFIGURATION:
  [ ] Default parol/sozlama o'zgartirilganmi?
  [ ] Xavfsizlik header'lari bormi? (helmet/CSP — 14.7)

A06 COMPONENTS:
  [ ] npm audit toza? (zaif paket yo'q — 14.9)

A07 AUTH:
  [ ] Kuchli parol talabi? Rate limiting? (brute force — 14.8)

A09 LOGGING:
  [ ] Xato/hujum loglanadimi? Monitoring bormi? (Sentry — 13.10)

Bu nima qiladi: Bu — xavfsizlik auditi ro'yxati (OWASP Top 10 bo'yicha tizimli tekshiruv — 2.2). Ilova tayyor bo'lgach (yoki ishlab turganda), uni OWASP Top 10 bo'yicha tekshirish kerak (har zaiflik bormi?). Ro'yxat har "A" kategoriya uchun aniq savollar: A01 (access control) — har resursda egalik/rol tekshiriladimi (IDOR — Misol 1), Server Action UI'dan tashqari himoyalanganmi (Misol 4); A02 (crypto) — parol bcrypt hashlanganmi, HTTPS majburiymi, secret env'dami; A03 (injection) — DB so'rovlar parametrlanganmi, kiritish validatsiya/sanitizatsiya qilinadimi; A05 (misconfig) — default sozlama o'zgartirilganmi, xavfsizlik header'lari bormi; A06 (components) — npm audit toza mi; A07 (auth) — kuchli parol, rate limiting; A09 (logging) — xato/hujum loglanadimi. Bu — amaliy xavfsizlik audit (har ilova deploy'dan oldin — yoki muntazam — shu ro'yxat bo'yicha tekshiriladi). Har savol — potensial zaiflik (agar javob "yo'q" bo'lsa — tuzatish kerak). Bu ro'yxat — OWASP Top 10'ni harakatga keltiradi (nazariya emas — amaliy tekshiruv). Professional jamoalarda bunday checklist bor (deploy'dan oldin xavfsizlik tekshiruvi — 2.5 — SDLC'ning test bosqichi). Bu kitobning keyingi boblari (14.2-14.8) har "A"ni chuqur ochadi (hujum + himoya), bu ro'yxat — ularning amaliy yig'indisi. Audit — xavfsizlikni o'lchovli qiladi (his-tuyg'u emas — aniq tekshiruv: A01 bormi? A03 bormi?). Har deploy'dan oldin shu ro'yxat (yoki avtomatlashtirilgan vositalar — SAST, DAST — 14.9) — xavfsizlik madaniyatining qismi. Bu — 14-QISMning yo'l xaritasi (har zaiflikni keyingi boblarda hal qilamiz).

Misol 6 — Cryptographic Failures (A02 — parol hash va secret)

Maqsad: A02'ning eng keng ikki xatosini — parolni ochiq (yoki zaif) saqlash va secret'ni kodga yozib qo'yish — ko'rsatish va to'g'ri shifrlash/hash usulini berish. Bu 14.5, 14.7'da chuqur, bu yerda mohiyat.

ts
//  ZAIF — parol ochiq yoki zaif (buzib bo'ladigan) usulda saqlanadi:
import crypto from "node:crypto";

async function register(email: string, password: string) {
  // Variant A — ochiq matn (DB sizsa — barcha parol hujumchida):
  await db.user.create({ data: { email, password } });        //  ochiq parol
  // Variant B — MD5/SHA1 (tez, "duz"siz — rainbow table bilan tez ochiladi):
  const weak = crypto.createHash("md5").update(password).digest("hex");
  await db.user.create({ data: { email, password: weak } });  //  zaif hash
}
//  DB sizib ketsa (A02 + A01), hujumchi barcha parolni biladi (yoki tez ochadi)

//  XAVFSIZ — sekin, "duz"li (salt) hash (bcrypt / argon2 — parolga moslashgan):
import bcrypt from "bcryptjs";

async function register(email: string, password: string) {
  // bcrypt — sekin (brute force qimmat) + har parolga alohida salt (avtomatik):
  const hash = await bcrypt.hash(password, 12);   // 12 — "cost" (sekinlik darajasi)
  await db.user.create({ data: { email, password: hash } });  //  faqat hash saqlanadi
}
async function login(email: string, password: string) {
  const user = await db.user.findUnique({ where: { email } });
  // Hech qachon parolni ochib solishtirmang — bcrypt.compare (constant-time):
  const ok = user && (await bcrypt.compare(password, user.password));
  if (!ok) throw new Error("Email yoki parol noto'g'ri");   // qaysi biri xato — aytma
}
ts
//  ZAIF — secret to'g'ridan kodda (git'ga tushadi — butun tarixda qoladi):
const stripe = new Stripe("sk_live_51H8xR2eZvKY...");   //  maxfiy kalit kodda!

//  XAVFSIZ — secret env'dan (kodda emas, .gitignore'da .env — 13.10):
const key = process.env.STRIPE_SECRET_KEY;
if (!key) throw new Error("STRIPE_SECRET_KEY sozlanmagan");   // fail securely (2.3)
const stripe = new Stripe(key);

Bu nima qiladi: Bu — Cryptographic Failures (A02 — OWASP 2-o'rni — shifrlash/maxfiylik xatolari). Ikki keng xato ko'rsatilgan. Birinchi — parol saqlash. Zaif kodda parol ochiq matnda (yoki md5/sha1 kabi tez va salt'siz hash bilan) saqlanadi. Muammo: agar DB sizib ketsa (masalan A01 yoki A03 orqali), ochiq parol darhol hujumchida bo'ladi, md5 esa "rainbow table" (oldindan hisoblangan jadval) bilan soniyalarda ochiladi. Xavfsiz kodda bcrypt (yoki argon2) ishlatiladi — bu parolga moslashgan funksiya: (1) ataylab sekin (brute force qimmatlashadi — sekundiga million emas, o'nlab urinish), (2) har parolga avtomatik salt (tuz) qo'shadi (bir xil parollar ham har xil hash beradi — rainbow table foydasiz). Solishtirishda bcrypt.compare ishlatiladi (constant-time — vaqt orqali ma'lumot sizmasin), va login xatosida "email yoki parol noto'g'ri" deyiladi (qaysi biri xato — oshkor qilinmaydi). Ikkinchi — secret boshqaruvi. Zaif kodda API kalit (sk_live_...) to'g'ridan manba kodga yoziladi — bu git tarixiga tushadi va abadiy qoladi (keyin o'chirsangiz ham, eski commit'da bor). Xavfsiz kodda secret environment o'zgaruvchidan (process.env) o'qiladi, .env esa .gitignore'da 13.10-bob. Tamoyil 2.3-bob: fail securely — secret yo'q bo'lsa, ilova ishlashda davom etmasdan xato beradi (jim o'tib ketmaydi). A02 ko'p tarmoqda: HTTPS majburiyligi (14.7 — TLS — ma'lumot yo'lda ochilmasin), shaxsiy ma'lumotni shifrlash, kuchli algoritm tanlash. Qoida: parolni hech qachon ochiq/qaytariladigan shifr bilan saqlamang (bir tomonlama hash), secret'ni hech qachon kodga yozmang (env).

Misol 7 — Security Misconfiguration (A05 — default va header)

Maqsad: A05'ning tipik ko'rinishlarini — verbose (batafsil) xato, default sozlama va yetishmayotgan xavfsizlik header'lari — ko'rsatish va to'g'ri sozlashni berish. Bu 14.7'da chuqur.

ts
//  ZAIF — production'da batafsil xato + himoya header'lari yo'q:
app.get("/api/data", async (req, res) => {
  try {
    const data = await db.query(req.query.sql);   // (alohida muammo — A03)
    res.json(data);
  } catch (err) {
    //  stack trace + DB tuzilishi foydalanuvchiga ochiladi (ma'lumot sizishi):
    res.status(500).json({ error: err.message, stack: err.stack });
  }
});
//  hujumchi xato matnidan DB nomi, jadval, yo'l, versiyani o'rganadi (razvedka)

//  XAVFSIZ — umumiy xato (tashqariga) + tafsilot logda + himoya header'lari:
import helmet from "helmet";
app.use(helmet());   //  xavfsizlik header'lari: CSP, X-Frame-Options, HSTS, ...
app.disable("x-powered-by");   //  texnologiya (Express) versiyasini oshkor qilma

app.get("/api/data", async (req, res) => {
  try {
    const data = await getData();
    res.json(data);
  } catch (err) {
    logger.error(err);   //  to'liq tafsilot — faqat logda (ichkarida)
    res.status(500).json({ error: "Server xatosi" });   //  umumiy xabar (tashqariga)
  }
});

Bu nima qiladi: Bu — Security Misconfiguration (A05 — OWASP 5-o'rni — noto'g'ri sozlash). Bu — kodning o'zi emas, balki sozlama darajasidagi zaiflik. Zaif kodda ikki muammo: (1) batafsil xato — catch bloki err.message va err.stack'ni to'g'ridan javobga qo'shadi. Bu hujumchiga bebaho razvedka beradi: DB turi va versiyasi, jadval nomlari, server yo'llari, ishlatilayotgan kutubxonalar — hammasi xato matnida ko'rinadi (keyingi hujumni aniq rejalashtirish uchun). (2) himoya header'lari yo'q — brauzer XSS, clickjacking, MIME sniffing'dan himoyasiz. Xavfsiz kodda: (1) xato tashqariga umumiy ("Server xatosi") beriladi, to'liq tafsilot esa faqat logga yoziladi (A09 — ichkarida ko'rinadi, tashqarida yo'q); (2) helmet middleware bir qatorda muhim xavfsizlik header'larini qo'yadi (CSP — Content-Security-Policy, X-Frame-Options — clickjacking'dan, HSTS — HTTPS majburlash, X-Content-Type-Options), (3) x-powered-by o'chiriladi (Express versiyasini oshkor qilmaslik — hujum yuzasini kamaytirish, 2.5). A05'ning boshqa tipik ko'rinishlari: default parol (admin/admin — o'zgartirilmagan), ochiq port (kerakmas xizmat internetga ochiq), debug rejimi production'da yoqilgan, ochiq S3 bucket. Qoida: production'da verbose emas, default'larni o'zgartiring, keraksizni o'chiring, xavfsizlik header'larini qo'ying. Xato xabari — foydalanuvchiga yordam berishi kerak, hujumchiga emas.

Misol 8 — Vulnerable Components (A06 — eski paketlar)

Maqsad: A06'ning mohiyatini — sizning kodingiz toza bo'lsa ham, ishlatgan kutubxonangizdagi zaiflik ilovangizni ochib qo'yishini — va uni topish/tuzatish jarayonini ko'rsatish. Bu 14.9'da chuqur.

bash
#  ZAIF — bog'liqliklar hech qachon tekshirilmaydi/yangilanmaydi:
# package.json'da eski versiyalar yillar davomida qotib qolgan.
# Masalan zaif "lodash@4.17.4" (prototype pollution — CVE bor) yoki
# eski "next" (SSRF/XSS tuzatilmagan) — kodingiz toza, lekin teshik paketda.

#  XAVFSIZ — muntazam audit + yangilash (SCA — Software Composition Analysis):
npm audit                    # ma'lum zaifliklarni ko'rsatadi (CVE bo'yicha)
npm audit fix                # xavfsiz avtomatik yangilanadigan zaifliklarni tuzatadi
npm audit fix --force        # major yangilanish (ehtiyot — buzilishi mumkin, test qiling)
npm outdated                 # eskirgan paketlarni ro'yxatlaydi

# CI/CD'da avtomatik (har PR'da audit; kritik zaiflik topilsa — build to'xtaydi):
#   - GitHub Dependabot (avtomatik yangilash PR'lari ochadi)
#   - Snyk / npm audit CI bosqichida

Bu nima qiladi: Bu — Vulnerable and Outdated Components (A06 — OWASP 6-o'rni — zaif komponentlar). Mohiyat: zamonaviy ilova o'nlab (ba'zan yuzlab) uchinchi tomon kutubxonasidan tashkil topadi (node_modules — ba'zan minglab paket). Sizning kodingiz mukammal xavfsiz bo'lishi mumkin, lekin agar ishlatgan paketingizda ma'lum zaiflik (CVE — Common Vulnerabilities and Exposures) bo'lsa — ilovangiz o'sha teshik orqali ochiladi. Mashhur misollar: lodash'dagi prototype pollution, log4j'dagi Log4Shell (butun internetni larzaga solgan), eski next/express versiyalaridagi SSRF/XSS. Zaif holat — bog'liqliklar bir marta o'rnatilib, yillar davomida yangilanmaydi (eski, zaif versiyalar qotib qoladi). Xavfsiz yondashuv — SCA (Software Composition Analysis): (1) npm audit — o'rnatilgan paketlarni ma'lum zaifliklar bazasiga solishtiradi; (2) npm audit fix — mos keladigan (buzmaydigan) yangilanishlarni avtomatik qo'llaydi; (3) npm outdated — eskirganlarni ko'rsatadi; (4) CI/CD'da avtomatlashtirish — har PR'da audit ishlaydi, kritik zaiflik topilsa build to'xtaydi; (5) Dependabot (yoki Snyk) — yangilanishlar chiqqanda avtomatik PR ochadi. Qoida: kutubxonani muntazam yangilang (ayniqsa xavfsizlik yamog'lari), npm audit'ni CI'ga qo'ying, ishlatilmaydigan paketni o'chiring (hujum yuzasi — 2.5). Bog'liqlikni qo'shishdan oldin — uning faolligi, obro'si, ochiq zaifliklarini tekshiring (har paket — ishonch va hujum yuzasi).

Misol 9 — Authentication Failures (A07 — brute force va sessiya)

Maqsad: A07'ning eng keng ko'rinishi — parolni cheksiz taxminlashga (brute force) yo'l qo'yish — va rate limiting bilan himoyani ko'rsatish. Bu 14.5, 14.8'da chuqur.

ts
//  ZAIF — login urinishlari cheksiz (parolni taxminlash mumkin):
app.post("/login", async (req, res) => {
  const { email, password } = req.body;
  const user = await db.user.findUnique({ where: { email } });
  if (user && (await bcrypt.compare(password, user.password))) {
    return res.json({ token: createSession(user) });
  }
  res.status(401).json({ error: "Noto'g'ri" });
  //  hujumchi bot bilan sekundiga minglab parol sinaydi (brute force / credential stuffing)
});

//  XAVFSIZ — rate limiting (urinishni cheklash) + account lockout:
import rateLimit from "express-rate-limit";

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,          // 15 daqiqa oynasi
  max: 5,                            // IP'dan maksimal 5 urinish
  message: "Juda ko'p urinish — 15 daqiqadan keyin qayta urinib ko'ring",
  standardHeaders: true,
});

app.post("/login", loginLimiter, async (req, res) => {
  const { email, password } = req.body;
  const user = await db.user.findUnique({ where: { email } });
  if (!user || !(await bcrypt.compare(password, user.password))) {
    // Bir xil, umumiy xabar (qaysi biri xato — oshkor qilma):
    return res.status(401).json({ error: "Email yoki parol noto'g'ri" });
  }
  res.json({ token: createSession(user) });   // sessiya — HttpOnly, Secure cookie'da
});

Bu nima qiladi: Bu — Identification and Authentication Failures (A07 — OWASP 7-o'rni — autentifikatsiya xatolari). Zaif kodda login endpoint'i cheksiz urinishga ruxsat beradi: hujumchi bot yordamida sekundiga minglab parol sinab ko'radi. Ikki hujum: (1) brute force — bitta hisobga barcha mumkin parollarni sinash; (2) credential stuffing — boshqa sayt sizishidan olingan million email/parol juftligini sinash (odamlar parolni takrorlaydi). Xavfsiz kodda rate limiting qo'shiladi: express-rate-limit bir IP'dan 15 daqiqada 5 urinishga cheklaydi (6-urinish — bloklanadi). Bu brute force'ni amalda imkonsiz qiladi (million parol sinash uchun asrlar kerak bo'ladi). Qo'shimcha himoyalar: (1) login xatosida bir xil umumiy xabar ("email yoki parol noto'g'ri" — qaysi biri noto'g'riligini aytmang, aks holda hujumchi mavjud email'larni aniqlaydi); (2) sessiya token'i HttpOnly + Secure cookie'da (JavaScript o'qiy olmaydi — XSS bilan o'g'irlanmaydi, faqat HTTPS'da uzatiladi); (3) kuchli parol talabi, 2FA (ikki bosqichli), ko'p muvaffaqiyatsiz urinishda account lockout. Tamoyil 2.4-bob: hujumchi ko'zi bilan — "1 million so'rov yuborsam?". A07 ko'p tarmoqda: zaif/default parol, sessiyani noto'g'ri boshqarish (logout'da bekor qilmaslik, token muddatsizligi), zaif parol tiklash (Misol 3). Qoida: har autentifikatsiya nuqtasini rate limiting bilan himoyalang 14.8-bob, sessiyani xavfsiz saqlang.

Misol 10 — Data Integrity Failures (A08 — webhook imzosi)

Maqsad: A08'ning amaliy ko'rinishi — tashqi manbadan (webhook) kelgan ma'lumotni imzo tekshirmasdan ishonish — va imzo tekshirish bilan himoyani ko'rsatish.

ts
//  ZAIF — webhook'ni imzosiz qabul qiladi (kim bo'lsa ham yuborishi mumkin):
app.post("/webhook/stripe", async (req, res) => {
  const event = req.body;
  if (event.type === "checkout.session.completed") {
    //  ishonch: hujumchi soxta so'rov yuborsa — bepul "to'landi" bo'ladi!
    await markOrderPaid(event.data.object.metadata.orderId);
  }
  res.json({ received: true });
});

//  XAVFSIZ — imzo tekshiriladi (faqat haqiqiy Stripe yuborgani qabul qilinadi):
app.post("/webhook/stripe", express.raw({ type: "application/json" }), (req, res) => {
  const sig = req.headers["stripe-signature"] as string;
  let event: Stripe.Event;
  try {
    // Stripe imzoni maxfiy kalit bilan tekshiradi — soxta so'rov o'tmaydi:
    event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch {
    return res.status(400).json({ error: "Imzo noto'g'ri" });   // fail securely
  }
  if (event.type === "checkout.session.completed") {
    markOrderPaid((event.data.object as any).metadata.orderId);
  }
  res.json({ received: true });
});

Bu nima qiladi: Bu — Software and Data Integrity Failures (A08 — OWASP 8-o'rni — ma'lumot va dastur yaxlitligi xatolari). Mohiyat: tashqi manbadan kelgan ma'lumotning haqiqatan o'sha manbadan kelganiga ishonch hosil qilmaslik. Klassik misol — webhook (Stripe kabi to'lov tizimi sizning server'ingizga "to'lov muvaffaqiyatli" deb xabar yuboradi). Zaif kodda server bu so'rovni imzo tekshirmasdan qabul qiladi — hujumchi endpoint manzilini bilsa (yoki topsa), o'zi soxta checkout.session.completed so'rovi yuboradi va bepul buyurtmani "to'langan" qilib qo'yadi. Xavfsiz kodda: Stripe har webhook'ga imzo (stripe-signature header) qo'shadi, u faqat siz va Stripe biladigan maxfiy kalit (STRIPE_WEBHOOK_SECRET) bilan yaratilgan. constructEvent bu imzoni tekshiradi — agar so'rov soxta bo'lsa (yoki o'zgartirilgan bo'lsa), imzo mos kelmaydi va so'rov rad etiladi (400 — fail securely). A08'ning boshqa ko'rinishlari: (1) ishonchsiz deserializatsiya (tashqaridan kelgan seriyalangan obyektni ko'r-ko'rona tiklash — kod bajarilishiga olib kelishi mumkin); (2) CI/CD supply chain hujumi (buzilgan build quvuri orqali zararli kod kiritish); (3) SRI yo'qligi (CDN'dan yuklangan skript o'zgartirilsa — integrity hash bilan tekshirilmaydi — 14.7); (4) tekshirilmagan avtomatik yangilanish. Qoida: tashqaridan kelgan ma'lumotning manbasini va yaxlitligini tekshiring (imzo, hash), ishonchsiz manbadan kelgan narsani ko'r-ko'rona bajarmang.

Misol 11 — Logging & Monitoring Failures (A09 — audit log)

Maqsad: A09'ning mohiyati — muhim xavfsizlik hodisalari loglanmasa, hujum sezilmay qolishi — va to'g'ri audit logni ko'rsatish. Bu 13.10, 8.26'da chuqur.

ts
//  ZAIF — muhim hodisalar loglanmaydi (hujum sezilmaydi):
app.post("/login", async (req, res) => {
  const user = await authenticate(req.body);
  if (!user) return res.status(401).json({ error: "Noto'g'ri" });
  //  hech qanday log — kim, qachon, qayerdan kirdi/kira olmadi — noma'lum
  res.json({ token: createSession(user) });
});
//  10 000 muvaffaqiyatsiz login bo'lsa ham — hech kim bilmaydi (hujum ko'rinmaydi)

//  XAVFSIZ — xavfsizlik hodisalari loglanadi + monitoring/alert:
app.post("/login", async (req, res) => {
  const user = await authenticate(req.body);
  if (!user) {
    logger.warn("login_failed", {                 //  audit log (kim, qayerdan, qachon)
      email: req.body.email, ip: req.ip, ts: new Date().toISOString(),
    });
    return res.status(401).json({ error: "Email yoki parol noto'g'ri" });
  }
  logger.info("login_success", { userId: user.id, ip: req.ip });
  res.json({ token: createSession(user) });
});
// Monitoring (Sentry/alert): "1 daqiqada bir IP'dan 50 login_failed"  ogohlantirish

Bu nima qiladi: Bu — Security Logging and Monitoring Failures (A09 — OWASP 9-o'rni — log va monitoring xatolari). Mohiyat: agar muhim xavfsizlik hodisalari (login, ruxsat rad etish, xato, o'zgartirish) loglanmasa yoki loglar kuzatilmasa, hujum sezilmay o'tadi. Statistika: ko'p buzilish oylar davomida sezilmaydi (o'rtacha aniqlash vaqti — juda uzoq), chunki hech kim loglarni ko'rmaydi. Zaif kodda login endpoint hech nima yozmaydi — bir IP'dan 10 000 muvaffaqiyatsiz urinish bo'lsa ham (aniq brute force hujum belgisi), hech kim bilmaydi. Xavfsiz kodda: (1) audit log — har muhim hodisa strukturaviy yoziladi (kim — email/userId, qayerdan — ip, qachon — ts, nima — login_failed/login_success); (2) monitoring va alert — loglar avtomatik kuzatiladi (Sentry, yoki log yig'uvchi), anomaliya topilsa (masalan "1 daqiqada bir IP'dan 50 muvaffaqiyatsiz login") — jamoaga darhol ogohlantirish boradi 13.10-bob. Muhim: (1) yetarli loglang (login, ruxsat, o'zgartirish, to'lov, admin amali); (2) lekin maxfiy ma'lumotni logga yozmang (parol, token, karta raqami — log ham sizishi mumkin); (3) loglarni himoyalang (o'zgartirib bo'lmaydigan — hujumchi izini o'chira olmasin). Bu A09 boshqa zaifliklar bilan bog'liq — u hujumni oldini olmaydi, lekin aniqlashga va javob berishga imkon beradi (buzilgandan keyin — nima bo'lganini tushunish uchun ham zarur). Qoida: xavfsizlik hodisalarini loglang va kuzating (log yozib, ko'rmaslik — foydasiz).

Misol 12 — SSRF (A10 — server so'rovini majburlash)

Maqsad: A10 — Server-Side Request Forgery — mohiyatini ko'rsatish: foydalanuvchi bergan URL'ni server ko'r-ko'rona so'rasa, hujumchi ichki tarmoqqa yeta oladi. Bu 14.4'da chuqur.

ts
//  ZAIF — foydalanuvchi bergan URL'ni server tekshirmasdan so'raydi:
app.post("/fetch-image", async (req, res) => {
  const { url } = req.body;                 // foydalanuvchi bergan URL
  const response = await fetch(url);        //  har qanday URL'ni so'raydi!
  const buffer = await response.arrayBuffer();
  res.send(Buffer.from(buffer));
});
//  hujumchi: url = "http://169.254.169.254/latest/meta-data/" (cloud metadata!)
//   yoki "http://localhost:6379" (ichki Redis) — server ichki tarmoqqa yetadi

//  XAVFSIZ — URL validatsiya (faqat ruxsatli, tashqi manzil; ichki bloklangan):
import { isIP } from "node:net";

const ALLOWED_HOSTS = new Set(["images.example.com", "cdn.example.com"]);

app.post("/fetch-image", async (req, res) => {
  let parsed: URL;
  try { parsed = new URL(req.body.url); } catch { return res.status(400).json({ error: "URL noto'g'ri" }); }

  // 1) faqat https, 2) faqat ruxsatli host (allowlist — blocklist emas):
  if (parsed.protocol !== "https:" || !ALLOWED_HOSTS.has(parsed.hostname)) {
    return res.status(400).json({ error: "Ruxsat etilmagan manzil" });   // fail securely
  }
  // 3) ichki/xususiy IP'ni bloklash (127.x, 169.254.x, 10.x, 192.168.x):
  if (isIP(parsed.hostname) && isPrivateIp(parsed.hostname)) {
    return res.status(400).json({ error: "Ichki manzil taqiqlangan" });
  }
  const response = await fetch(parsed.href);
  res.send(Buffer.from(await response.arrayBuffer()));
});

Bu nima qiladi: Bu — SSRF (Server-Side Request Forgery — A10 — OWASP 10-o'rni — server so'rovini soxtalashtirish). Mohiyat: agar server foydalanuvchi bergan URL'ni ko'r-ko'rona so'rasa, hujumchi server'ni ichki tarmoqqa so'rov yuborishga majburlaydi. Zaif kodda /fetch-image foydalanuvchi bergan har qanday URL'ni fetch qiladi. Hujumchi tashqi rasm o'rniga: (1) http://169.254.169.254/latest/meta-data/ (cloud metadata endpoint — AWS/GCP'da server maxfiy kalitlari!) — server o'z nomidan so'raydi va natijani hujumchiga qaytaradi; (2) http://localhost:6379 (ichki Redis), http://10.0.0.5/admin (ichki xizmat) — tashqaridan yetib bo'lmaydigan ichki tizimlarga server orqali yetadi (server "ishonchli" ichki tarmoqda). Xavfsiz kodda: (1) URL parse qilinadi (buzuq URL — rad); (2) faqat https va allowlistdagi host'lar ruxsat (blocklist emas — allowlist ishonchliroq, chunki hamma yomon variantni sanab bo'lmaydi); (3) ichki/xususiy IP diapazonlari (127.x, 169.254.x, 10.x, 192.168.x) bloklanadi. Har rad etishda umumiy xato (fail securely — 2.3). Tamoyil 2.3-bob: never trust user input — URL ham foydalanuvchi ma'lumoti, ishonmang. SSRF ko'p joyda paydo bo'ladi: rasm yuklash URL'dan, webhook, PDF generatsiya, "URL preview". Qoida: server foydalanuvchi bergan URL'ga so'rov yuborishdan oldin — uni qat'iy validatsiya qiling (allowlist, ichkini blok — 14.4).

Misol 13 — Insecure Design (A04 — STRIDE va secure by design)

Maqsad: A04 — Insecure Design — kod xatosi emas, balki dizayn darajasidagi zaiflikni ko'rsatish: to'g'ri yozilgan kod ham xavfsiz emas dizaynni qutqarmaydi. STRIDE threat modeling asosini berish.

text
A04 — kodni to'g'ri yozish YETARLI EMAS — dizayn xavfsiz bo'lishi kerak.

 ZAIF DIZAYN — "chegirma kodi" cheksiz ishlatiladi:
   Foydalanuvchi bitta "PROMO50" kodini 1000 marta ishlatadi (dizaynda cheklov yo'q).
    kod mukammal yozilgan, lekin DIZAYN xato (biznes mantiq zaifligi).

 XAVFSIZ DIZAYN (secure by design) — cheklov dizaynga singdirilgan:
   Har kod: bir foydalanuvchiga bir marta + umumiy limit + muddat + atomik tekshiruv.

STRIDE — dizayn bosqichida tahdidlarni sanab chiqish uslubi (har harf — bir tahdid turi):
  S — Spoofing (o'zini boshqa qilib ko'rsatish)       autentifikatsiya (A07)
  T — Tampering (ma'lumotni o'zgartirish)             yaxlitlik/imzo (A08)
  R — Repudiation (qilganini inkor etish)             audit log (A09)
  I — Information Disclosure (ma'lumot sizishi)       shifrlash/ruxsat (A01, A02)
  D — Denial of Service (ishdan chiqarish)            rate limit (A07)
  E — Elevation of Privilege (imtiyozni oshirish)     ruxsat nazorati (A01)

   dizayn bosqichida har komponentga STRIDE'ni qo'llang: "bu qanday
    Spoof/Tamper/... qilinishi mumkin?" — keyin himoyani DIZAYNGA kiriting.

Bu nima qiladi: Bu — Insecure Design (A04 — OWASP 4-o'rni — xavfsiz emas dizayn). Bu OWASP 2021'da qo'shilgan yangi va muhim kategoriya. Farqi: boshqa zaifliklar ko'pincha amalga oshirish (implementation) xatosi (kod noto'g'ri yozilgan), A04 esa dizayn xatosi — kod mukammal yozilgan bo'lishi mumkin, lekin arxitektura/biznes mantiqning o'zi zaif. Misol: "chegirma kodi" funksiyasi. Kod toza yozilgan (injection yo'q, auth bor), lekin dizaynda "har kod bir marta ishlatiladi" cheklovi umuman o'ylanmagan — foydalanuvchi bitta PROMO50'ni 1000 marta ishlatib, do'konni sindiradi. Hech qanday kod tuzatish buni hal qilmaydi — dizaynni o'zgartirish kerak (cheklovni dizaynga singdirish: bir foydalanuvchiga bir marta, umumiy limit, muddat, atomik tekshiruv — poyga holatiga qarshi). Bu — "secure by design" (xavfsizlik boshidan dizaynga kiritilgan, keyin "yamoq" emas — 2.5 shift-left). Buni ta'minlaydigan uslub — STRIDE (Microsoft'ning threat modeling metodikasi): har komponent uchun oltita tahdid turini sanab chiqing — Spoofing (o'zini boshqa qilib ko'rsatish autentifikatsiya), Tampering (ma'lumotni buzish imzo/yaxlitlik), Repudiation (inkor audit log), Information disclosure (sizish shifrlash/ruxsat), Denial of service (ishdan chiqarish rate limit), Elevation of privilege (imtiyozni oshirish ruxsat nazorati). Dizayn bosqichida har komponentga "bu qanday Spoof/Tamper/... qilinadi?" savolini berib, himoyani oldindan dizaynga kiritasiz. Qoida: xavfsizlikni kod yozishdan oldin — dizaynda o'ylang (threat model — 2.1, Misol 3). Yaxshi dizayn yomon kodni qisman qutqaradi, lekin mukammal kod yomon dizaynni qutqarmaydi.

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

1) Foydalanuvchi kiritishi

text
 ishonish (to'g'ri deb qabul — injection/XSS — 2.3)
 never trust input (validatsiya + sanitizatsiya — 14.2, 14.3)

2) Himoya qatlami

text
 faqat UI yashirish (so'rov to'g'ridan — ochiq — Misol 4)
 defense in depth (server'da ham — 2.3, Misol 4)

3) Ruxsat

text
 faqat login tekshir (egalik/rol yo'q — IDOR — A01)
 egalik + rol har resursda (Misol 1)

4) Xato holati

text
 xato bo'lsa ruxsat ber (fail open — xavfli)
 fail securely (xato  rad et — 2.3)

5) Secret

text
 kodda/git'da secret (sizib ketadi — A02)
 env'da 13.10-bob; ochiq parol yo'q (bcrypt — 14.5)

6) Imtiyoz

text
 hammaga to'liq ruxsat (least privilege buzilgan)
 faqat kerakli ruxsat (default minimal — 2.3)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — "Bizni hech kim hujum qilmaydi" (e'tiborsizlik)

Sababi: xavfsizlik keyinga qoldiriladi. Yechimi: avtomatik botlar har saytni sinaydi (mashhurlik shart emas); xavfsizlik boshidan 2.5-bob.

Xato 2 — Faqat UI'da himoya

Sababi: tugmani yashirish himoya deb o'ylash (Misol 4). Yechimi: server'da tekshir (defense in depth — 2.3).

Xato 3 — Foydalanuvchi ma'lumotiga ishonish

Sababi: kiritish to'g'ri deb qabul (injection/XSS). Yechimi: never trust input — validatsiya (2.3, 14.2).

Xato 4 — IDOR (boshqa ID'ni ko'rsatish)

Sababi: egalik tekshirilmaydi (A01 — Misol 1). Yechimi: har resursda egalik tekshir.

Xato 5 — Eski/zaif kutubxonalar

Sababi: npm audit ishlatilmaydi (A06). Yechimi: muntazam npm audit + yangilash 14.9-bob.

Xato 6 — Xato xabari ko'p ma'lumot beradi

Sababi: stack trace/DB xato foydalanuvchiga (ma'lumot sizishi). Yechimi: umumiy xabar (production'da — 13.10), tafsilot logda.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Auth 13.9-bob: A01 (access control), A07 (auth failures) — login/rol.
  • Backend (5, 8-QISM): injection (A03), validatsiya, rate limiting.
  • DB (6-QISM): SQL injection (A03), least privilege.
  • Deploy 13.10-bob: secret, HTTPS, monitoring (A02, A09).
  • Route Handlers/Middleware 13.6-bob: CORS, headers, webhook imzo.
  • Forms (11.10, 13.5): validatsiya (Zod — injection/XSS oldini).
  • Barcha QISM: xavfsizlik — har qatlamda (frontend, backend, DB, deploy).

8. Eng yaxshi amaliyotlar (best practices)

  • Never trust user input (validatsiya + sanitizatsiya — 2.3).
  • Defense in depth (ko'p qatlam — Misol 4).
  • Least privilege (faqat kerakli ruxsat — 2.3).
  • Fail securely (xato rad et — 2.3).
  • OWASP Top 10 audit (muntazam tekshir — Misol 5).
  • Hujumchi tafakkuri (har funksiyaga "buziladimi?" — 2.4).
  • Hujum yuzasini kamaytir (keraksizni o'chir — 2.5).
  • Xavfsizlik har bosqichda (dizayndeploy — shift left — 2.5).
  • Secret env'da (kodda emas — A02).
  • Monitoring (hujum sezilsin — A09, 13.10).

9. Amaliy loyiha: "Xavfsizlik Auditi"

OWASP Top 10 bo'yicha ilovani tekshirish va himoyalashni mustahkamlash.

Maqsad

Mavjud ilovani (13.11 capstone yoki boshqa) OWASP Top 10 bo'yicha audit qil va zaifliklarni tuzat.

Talablar (requirements)

  1. Threat model: asosiy funksiyalarga (login, to'lov, ma'lumot — 2.1, Misol 3).
  2. A01 audit: har resursda egalik/rol tekshir (IDOR — Misol 1).
  3. A03 audit: DB so'rovlar parametrlanganmi (Misol 2).
  4. Defense in depth: har himoya ko'p qatlam (Misol 4).
  5. Hujumchi tafakkuri: har funksiyaga "qanday buziladi?" 2.4-bob.
  6. Audit ro'yxati: OWASP Top 10 checklist (Misol 5).
  7. Secret tekshir: kodda/git'da secret yo'qmi (A02).
  8. npm audit: zaif paket yo'qmi (A06).
  9. Fail securely: xato holatlari xavfsizmi 2.3-bob.
  10. Hisobot: topilgan zaifliklar + tuzatish (audit hujjati).

Maslahatlar (hint)

  • Hujumchi ko'zi bilan (buziladimi? — 2.4).
  • Har resursda egalik (IDOR — Misol 1).
  • Faqat UI emas — server (Misol 4).
  • Never trust input 2.3-bob.
  • OWASP checklist (Misol 5).

"Tayyor" mezonlari (acceptance criteria)

  • Threat model (asosiy funksiyalar).
  • A01-A10 audit (har biri tekshirilgan).
  • IDOR yo'q (egalik tekshir).
  • Injection yo'q (parametrlangan).
  • Defense in depth (ko'p qatlam).
  • Secret xavfsiz (env).
  • npm audit toza.
  • Audit hisoboti.

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

10. Xulosa va keyingi bobga ko'prik

Bu bobda web xavfsizligi va OWASP Top 10'ni umumiy o'rgandik:

  • Xavfsizlik/CIA 2.1-bob; OWASP Top 10 2.2-bob; tamoyillar (defense in depth, least privilege — 2.3); hujumchi tafakkuri 2.4-bob; hujum yuzasi/SDLC 2.5-bob.

Endi siz xavfsizlik tafakkuriga egasiz: ilovani hujumchi ko'zi bilan ko'rish ("buziladimi?"), OWASP Top 10'ni bilish, va xavfsizlik tamoyillarini (defense in depth, never trust input) qo'llash. Bu — keyingi boblarning (har zaiflik chuqur) poydevori.

Keyingi bob — 14.2-bob: XSS (Cross-Site Scripting). OWASP A03'ning bir qismi — eng keng frontend hujumi: XSS — hujumchi sahifaga yomon JavaScript kiritadi (boshqa foydalanuvchi brauzer'ida ishlaydi — cookie/sessiya o'g'irlik). XSS turlari (stored, reflected, DOM), hujum misollari, va himoya (sanitizatsiya, CSP, React'ning o'rnatilgan himoyasi). Bu — frontend dasturchining majburiy bilimi.

Foydalanilgan rasmiy/ishonchli manbalar

  • OWASP rasmiy (owasp.org) — "OWASP Top 10 (2021)", har zaiflik (A01-A10) tavsifi va himoya
  • OWASP ASVS (Application Security Verification Standard) — batafsil tekshiruv standarti (L1-L3)
  • OWASP Cheat Sheet Series — har mavzuga (parol, XSS, JWT, ...) amaliy "to'g'ri qilish" qo'llanmasi
  • OWASP Threat Modeling — dizayn bosqichida tahdid tahlili (STRIDE bilan)
  • Microsoft STRIDE — threat modeling metodikasi (Spoofing/Tampering/... — 2.6)
  • NIST Zero Trust Architecture (SP 800-207) — "never trust, always verify" modeli
  • PortSwigger Web Security Academy — interaktiv xavfsizlik darslari (bepul, amaliy laboratoriyalar)
  • MITRE CWE (Common Weakness Enumeration) va CVE (Common Vulnerabilities and Exposures) — zaifliklar katalogi
  • MDN Web Security — brauzer xavfsizligi, CSP, HTTPS, cookie xususiyatlari
  • Node.js / Express xavfsizlik qo'llanmasi — helmet, rate limiting, xato boshqaruvi

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
14.1-bob: Web xavfsizligi va OWASP Top 10 — Wisar