WisarWisar
Dasturlash kitobi/14-QISM — Xavfsizlik30 daqiqa

14.4-bob: CSRF va SSRF

14-QISM — Web Xavfsizligi · 4-mavzu

1. Kirish va motivatsiya

Bu bobda ikki nomi o'xshash, lekin mohiyati boshqa bo'lgan hujumni ko'ramiz: CSRF (Cross-Site Request Forgery — saytlararo so'rov soxtalashtirish) va SSRF (Server-Side Request Forgery — server tomonidan so'rov soxtalashtirish). CSRF — foydalanuvchini bilmasdan amal qildirishdir: hujumchi soxta sahifa quradi, foydalanuvchi (allaqachon sizning saytingizga kirgan) o'sha sahifani ochsa, uning brauzeri avtomatik sizning saytingizga so'rov yuboradi (cookie bilan) — masalan pul o'tkazadi, parol o'zgartiradi (foydalanuvchi bilmasdan). SSRF esa boshqacha: hujumchi serverni o'zi uchun yomon so'rov yuborishga majburlaydi (masalan ichki tizimlarga, bulut metama'lumotlariga kirish) — server "ishonchli" bo'lgani uchun, ichki resurslarga yetib boradi.

CSRF — ilgari juda keng tarqalgan edi (banklar, ijtimoiy tarmoqlar), va hali ham muhim (ayniqsa cookie-asosli autentifikatsiyada). SSRF esa zamonaviy, bulut (cloud) davrida juda xavfli bo'lib qoldi — OWASP Top 10'ga (A10) qo'shildi. Capital One bank'ining millionlab mijoz ma'lumoti sizishi (2019) — SSRF orqali bo'lgan. Ikkalasi ham "soxta so'rov" haqida (CSRF — foydalanuvchi brauzeridan, SSRF — serverdan), lekin himoyalari farq qiladi. Bu bob ikkalasini (hujum + himoya) ochadi.

Bu bob: CSRF nima va qanday ishlaydi, CSRF hujum misoli (soxta forma), CSRF himoyasi (SameSite cookie, CSRF token), SSRF nima va qanday ishlaydi, SSRF hujum misoli (ichki tarmoq, bulut metama'lumot), va SSRF himoyasi (URL validatsiya, allowlist). Ikki hujumni ham to'liq — mexanizmdan himoyagacha — ko'rib chiqamiz.

O'xshatish: CSRF — bu soxta imzo bilan chek. Tasavvur qiling, sizning bankingiz chek faqat imzo (cookie — siz kirgansiz) bilan amal qiladi. Hujumchi sizga "tabriknoma" (soxta sahifa) yuboradi, siz uni ochasiz — va u yashirin ravishda "10 million so'mni hujumchiga o'tkaz" chekini sizning imzoyingiz (cookie — brauzer avtomatik qo'shadi) bilan bankka yuboradi. Bank imzoni ko'rib (haqiqiy — sizniki) bajaradi. Himoya — bank qo'shimcha maxfiy kod so'raydi (CSRF token — faqat haqiqiy sahifada bor, soxta sahifada yo'q). SSRF esa — bu ishonchli xodimni aldab ish bajartirish: hujumchi (tashqi odam) seyf xonasiga kira olmaydi, lekin xodimni (server) "menga seyfdan hujjatni olib chiqing" deb aldaydi — xodim ishonchli (ichki kirish huquqi bor), shuning uchun hujumchi uning orqali ichkariga yetadi.

Nega muhim?

  • CSRF — cookie-auth saytlarda keng (foydalanuvchi bilmasdan amal — pul, parol).
  • SSRF (A10) — zamonaviy, bulut davrida juda xavfli (Capital One — millionlab sizish).
  • Soxta so'rov — ikkalasi ham (brauzerdan/serverdan) — ishonchni suiiste'mol.
  • Himoya oddiy — SameSite cookie + CSRF token (CSRF), URL validatsiya (SSRF).

2. Nazariya — chuqur tushuntirish

2.1. CSRF nima va qanday ishlaydi

text
  CSRF — foydalanuvchini BILMASDAN amal qildirish (cookie suiiste'moli):

  SHART: foydalanuvchi saytga KIRGAN (cookie bor) + sayt cookie bilan auth qiladi
   brauzer har so'rovga COOKIEni AVTOMATIK qo'shadi (boshqa saytdan ham!)

  HUJUM OQIMI:
  1. Foydalanuvchi bankka kirgan (cookie bor, brauzerda)
  2. Hujumchi soxta sahifa quradi (yoki email/havola)
  3. Foydalanuvchi soxta sahifani ochadi
  4. Soxta sahifa bankka so'rov yuboradi (pul o'tkazish):
     <form action="https://bank.com/transfer" method="POST">
       <input name="to" value="hujumchi"><input name="amount" value="10000000">
     </form> <script>form.submit()</script>
  5. Brauzer COOKIEni AVTOMATIK qo'shadi (foydalanuvchi kirgan)  bank bajaradi!

   CSRF — soxta saytdan so'rov, brauzer cookieni avtomatik qo'shadi (foydalanuvchi bilmaydi)
   Shart — cookie-asosli auth (token header'da bo'lsa — CSRF kamroq, 14.6)

CSRF nima va qanday ishlaydi — CSRF hujumining mexanizmi. CSRF — foydalanuvchini bilmasdan amal qildirish (cookie suiiste'moli). Shart: (1) foydalanuvchi saytga kirgan (cookie bor brauzerda); (2) sayt cookie bilan autentifikatsiya qiladi. Asosiy muammo — brauzer har so'rovga cookie'ni avtomatik qo'shadi, hatto boshqa saytdan yuborilgan so'rovga ham (bu brauzer dizaynining xususiyati). Hujum oqimi: (1) foydalanuvchi bankka kirgan (cookie bor); (2) hujumchi soxta sahifa quradi (yoki email/havola yuboradi); (3) foydalanuvchi soxta sahifani ochadi (oddiy ko'rinadi — "tabriknoma", "yutuq"); (4) soxta sahifa yashirin ravishda bankka so'rov yuboradi (<form action="https://bank.com/transfer" method="POST"> — pul o'tkazish — JavaScript bilan avtomatik submit); (5) brauzer cookie'ni avtomatik qo'shadi (foydalanuvchi bankka kirgan — cookie bor) bank so'rovni "haqiqiy foydalanuvchidan" deb qabul qiladi va bajaradi (pul o'tkaziladi — foydalanuvchi bilmasdan). Ikki nuqta: (1) CSRF — soxta saytdan so'rov, brauzer cookie'ni avtomatik qo'shadi (foydalanuvchi bilmaydi — "men hech narsa qilmadim" deydi); (2) shart — cookie-asosli auth (agar token header'da bo'lsa — masalan Authorization: Bearer — CSRF kamroq, chunki header avtomatik qo'shilmaydi — 14.6). CSRF — cookie autentifikatsiyani ishlatadigan saytlarning klassik zaifligi. Mohiyat — brauzer cookie'ni avtomatik qo'shishidan foydalanish (foydalanuvchi niyatisiz so'rov). Himoya 2.3-bob — so'rov haqiqatan foydalanuvchi sahifasidan kelganini tasdiqlash.

2.2. CSRF nimaga ta'sir qiladi

text
  CSRF — FAQAT "AMAL" so'rovlariga (state o'zgartiruvchi — GET emas):

  XAVFLI (state o'zgartiradi — CSRF nishoni):
   POST/PUT/DELETE — pul o'tkazish, parol o'zgartirish, o'chirish, sozlama
   "foydalanuvchi nomidan amal" (uning cookie'si bilan)

  XAVFSIZROQ (faqat o'qish — GET):
   GET — ma'lumot olish (CSRF state o'zgartirmaydi, lekin ma'lumot sizishi mumkin)
   MUHIM: GET amal QILMASLIGI kerak (GET /delete?id=5 — XATO dizayn!)

  CSRF NIMA QILA OLMAYDI:
   Javobni O'QIY olmaydi (soxta sayt javobni ko'rmaydi — CORS to'sadi)
   faqat "yuboradi" (amal qildiradi), natijani ko'rmaydi

   CSRF — state o'zgartiruvchi amallar (POST/PUT/DELETE — pul, parol, o'chirish)
   GET hech qachon amal qilmasin (REST — GET faqat o'qish — 7-QISM)

CSRF nimaga ta'sir qiladi — CSRF qaysi so'rovlarga ta'sir qiladi. CSRF faqat "amal" (state o'zgartiruvchi) so'rovlarga ta'sir qiladi: xavfli — POST/PUT/DELETE (pul o'tkazish, parol o'zgartirish, ma'lumot o'chirish, sozlama o'zgartirish — "foydalanuvchi nomidan amal" — uning cookie'si bilan); xavfsizroq — GET (faqat o'qish — CSRF state o'zgartirmaydi, garchi ba'zan ma'lumot sizishi mumkin). Juda muhim: GET so'rovi hech qachon amal qilmasligi kerak (masalan GET /delete?id=5 — bu xato dizayn — GET amal qiladi CSRF oson — hujumchi <img src="bank.com/delete?id=5"> bilan ham qila oladi). REST tamoyili (7-QISM): GET faqat o'qish, amal — POST/PUT/DELETE. CSRF nima qila olmaydi: javobni o'qiy olmaydi — soxta sayt so'rov yuboradi (amal qildiradi), lekin javobni ko'rmaydi (CORS — 13.6 — boshqa domen javobni o'qishni to'sadi). Demak CSRF "ko'r" hujum — amal qildiradi, lekin natijani bilmaydi (masalan pul o'tkazadi, lekin "muvaffaqiyatlimi?" javobini ko'rmaydi — lekin amal bajarilgan). Ikki nuqta: (1) CSRF — state o'zgartiruvchi amallar (POST/PUT/DELETE — pul, parol, o'chirish — zarar shularda); (2) GET hech qachon amal qilmasin (REST — GET faqat o'qish — agar GET amal qilsa, CSRF ham osonroq, ham keshlanish/log muammosi). Bu — CSRF himoyasi uchun muhim: amal so'rovlarni (POST/PUT/DELETE) himoyalash (CSRF token, SameSite — 2.3), va GET'ni amal uchun ishlatmaslik (to'g'ri REST dizayn). CSRF nishoni — "zararli amal" (foydalanuvchi niyatisiz bajariladigan).

2.3. CSRF himoyasi

text
  CSRF HIMOYASI — so'rov HAQIQATAN foydalanuvchi sahifasidan kelganini tasdiqlash:

  1. SAMESITE COOKIE (eng oson, zamonaviy — default himoya):
  cookie: { sameSite: "lax" yoki "strict" }
   cookie BOSHQA saytdan so'rovda YUBORILMAYDI (CSRF to'siladi)
   "strict" — har doim faqat o'z saytdan; "lax" — top-level navigatsiya OK

  2. CSRF TOKEN (an'anaviy, kuchli):
   server har formaga maxfiy token beradi (yashirin maydon)
   forma yuborilganda token tekshiriladi (soxta sahifada token YO'Q)
   faqat haqiqiy sahifa to'g'ri token yuboradi  tasdiqlanadi

  3. ORIGIN/REFERER HEADER tekshir:
   so'rov qaysi saytdan keldi (Origin header) — o'z saytdan bo'lsin

  4. TOKEN AUTH (cookie o'rniga — 14.6):
   token header'da (Authorization) — brauzer avtomatik qo'shmaydi (CSRF yo'q)

   CSRF himoya — SameSite cookie (eng oson) + CSRF token (kuchli) + Origin tekshir
   Auth.js/framework CSRF token avtomatik beradi (13.9 — qo'lda kam)

CSRF himoyasi — so'rov haqiqatan foydalanuvchi sahifasidan kelganini tasdiqlash. To'rt usul: (1) SameSite cookie (eng oson, zamonaviy — default himoya): cookie'ga sameSite: "lax" yoki "strict" bayrog'i — bu cookie'ni boshqa saytdan yuborilgan so'rovda yubormaslikni belgilaydi (CSRF to'siladi — soxta sayt so'rov yuborsa, cookie qo'shilmaydi bank "kirmagan" deb rad qiladi). "strict" — cookie faqat o'z saytdan (eng qattiq), "lax" — top-level navigatsiya (havola bosish) OK, lekin yashirin so'rov (forma, img) — yo'q (yaxshi balans — default tavsiya); (2) CSRF token (an'anaviy, kuchli): server har formaga maxfiy token beradi (yashirin maydon — <input type="hidden" name="csrf" value="...">), forma yuborilganda token tekshiriladi — soxta sahifada bu token yo'q (hujumchi uni bilmaydi — har sessiyaga noyob) soxta so'rov rad etiladi (faqat haqiqiy sahifa to'g'ri token yuboradi); (3) Origin/Referer header tekshir: so'rov qaysi saytdan kelganini (Origin header) tekshirish (o'z saytdan bo'lsin — boshqa domen rad); (4) token auth (cookie o'rniga — 14.6): token Authorization header'da bo'lsa, brauzer uni avtomatik qo'shmaydi (CSRF yo'q — soxta sayt header qo'sha olmaydi). Ikki nuqta: (1) CSRF himoya — SameSite cookie (eng oson — bir bayroq), CSRF token (kuchli — qo'shimcha tasdiq), Origin tekshir; (2) Auth.js va frameworklar 13.9-bob CSRF token'ni avtomatik beradi (qo'lda kam yozasiz — framework boshqaradi). Zamonaviy yondashuv: SameSite cookie (default — lax/strict) + token auth (header) yoki CSRF token (cookie auth bo'lsa). Ko'p framework (Next.js Server Actions, Auth.js) CSRF'ni avtomatik hal qiladi (SameSite + token). CSRF himoyasi nisbatan oddiy (SameSite cookie — bir qator), lekin muhim (cookie auth ishlatsangiz).

2.4. SSRF nima va qanday ishlaydi

text
  SSRF — serverni yomon so'rov yuborishga majburlash (server ishonchini suiiste'mol):

  SHART: server foydalanuvchi bergan URL'ga so'rov yuboradi (rasm, webhook, import)
   masalan: "URL'dan rasm yukla", "shu URL'dagi ma'lumotni import qil"

  HUJUM OQIMI:
  1. Sayt: "rasm URL'ini kiriting"  server o'sha URL'dan rasm oladi
  2. Hujumchi tashqi rasm o'rniga ICHKI URL beradi:
     http://localhost:6379         (ichki Redis)
     http://169.254.169.254/...    (bulut metama'lumot — AWS — eng xavfli!)
     http://internal-api/admin     (ichki tizim)
  3. Server o'sha URL'ga so'rov yuboradi (server ichki tarmoqdan — ishonchli)
  4. Ichki ma'lumot (bulut kalitlari, ichki API) hujumchiga qaytadi!

   SSRF — server foydalanuvchi URL'iga so'rov (ichki tizim/bulut metama'lumotga kirish)
   Eng xavfli — bulut metama'lumot (169.254.169.254 — IAM kalitlari — Capital One)

SSRF nima va qanday ishlaydi — SSRF hujumining mexanizmi. SSRF — serverni yomon so'rov yuborishga majburlash (server ishonchini suiiste'mol). Shart: server foydalanuvchi bergan URL'ga so'rov yuboradi (masalan "URL'dan rasm yukla", "shu URL'dagi ma'lumotni import qil", webhook URL, avatar URL). Hujum oqimi: (1) sayt foydalanuvchidan URL so'raydi (masalan "rasm URL'ini kiriting" server o'sha URL'dan rasmni oladi va saqlaydi); (2) hujumchi tashqi rasm URL o'rniga ichki URL beradi: http://localhost:6379 (server'ning o'z Redis'i), http://169.254.169.254/latest/meta-data/ (bulut metama'lumot — AWS/GCP — eng xavfli — IAM kalitlari shu yerda), http://internal-api/admin (ichki tizim — tashqaridan kirib bo'lmaydigan); (3) server o'sha URL'ga so'rov yuboradi — server ichki tarmoqda (ishonchli — ichki resurslarga kira oladi — tashqi foydalanuvchi kira olmaydi); (4) ichki ma'lumot (bulut kalitlari, ichki API javobi) hujumchiga qaytadi (server uni foydalanuvchiga ko'rsatadi yoki saqlaydi). Ikki nuqta: (1) SSRF — server foydalanuvchi URL'iga so'rov (ichki tizim/bulut metama'lumotga kirish — server "ishonchli vakil" sifatida); (2) eng xavfli — bulut metama'lumot (169.254.169.254 — AWS/GCP/Azure'da bu IP IAM kalitlari, vaqtinchalik tokenlarni beradi — hujumchi bu kalitlar bilan butun bulut hisobini egallashi mumkin — Capital One bank 2019'da aynan shu orqali millionlab mijoz ma'lumotini yo'qotdi). SSRF zamonaviy, bulut davrida juda xavfli (OWASP A10). Mohiyat — server foydalanuvchi nazoratidagi URL'ga so'rov yuboradi, va server tashqi foydalanuvchi kira olmaydigan ichki resurslarga yetadi (server ishonchini suiiste'mol). Himoya 2.5-bob — qaysi URL'ga so'rov yuborishni cheklash.

2.5. SSRF himoyasi

text
  SSRF HIMOYASI — server qaysi URL'ga so'rov yuborishini cheklash:

  1. ALLOWLIST (faqat ruxsat etilgan domenlar — eng kuchli):
  const ALLOWED = ["images.cdn.com", "api.partner.com"];
  if (!ALLOWED.includes(new URL(userUrl).hostname)) throw "Ruxsat yo'q";

  2. ICHKI IP'LARNI BLOKLASH (denylist):
   127.0.0.1, localhost, 10.x, 172.16-31.x, 192.168.x (ichki tarmoq)
   169.254.169.254 (bulut metama'lumot — ALBATTA blokla)

  3. PROTOKOL CHEKLASH (faqat http/https):
   file://, gopher://, ftp:// — rad (faqat http/https)

  4. REDIRECT'NI KUZATMASLIK / tekshir:
   hujumchi tashqi URL  ichki URL'ga redirect qilishi mumkin (tekshir)

  5. DNS REBINDING himoya (IP'ni qayta tekshir):
   so'rov paytida IP qayta tekshir (DNS o'zgartirilishi mumkin)

   SSRF himoya — allowlist (eng kuchli) + ichki IP blok + protokol cheklash + redirect tekshir
   Bulut metama'lumot (169.254.169.254) — ALBATTA blokla (eng xavfli SSRF nishoni)

SSRF himoyasi — server qaysi URL'ga so'rov yuborishini cheklash. Besh usul: (1) allowlist (faqat ruxsat etilgan domenlar — eng kuchli): const ALLOWED = ["images.cdn.com", "api.partner.com"]; if (!ALLOWED.includes(new URL(userUrl).hostname)) throw — foydalanuvchi URL'ining domenini ruxsat etilgan ro'yxat bilan tekshirish (faqat ma'lum, ishonchli domenlar — qolgani rad — agar server faqat ma'lum manbalardan ma'lumot olsa, allowlist ideal); (2) ichki IP'larni bloklash (denylist): 127.0.0.1, localhost, 10.x, 172.16-31.x, 192.168.x (xususiy/ichki tarmoq IP'lari), va ayniqsa 169.254.169.254 (bulut metama'lumot — albatta blokla); (3) protokol cheklash (faqat http/https): file:// (server fayllari), gopher://, ftp:// — rad (faqat http/https — boshqa protokollar xavfli); (4) redirect'ni kuzatmaslik/tekshir: hujumchi tashqi (ruxsat etilgan) URL berib, u ichki URL'ga redirect qilishi mumkin (allowlist'ni chetlab o'tish) — redirect'ni kuzatmaslik yoki har qadamda tekshir; (5) DNS rebinding himoya: domen tekshiruv paytida ruxsat etilgan IP'ga, lekin so'rov paytida ichki IP'ga "o'zgarishi" mumkin (DNS rebinding) — so'rov paytida IP'ni qayta tekshir. Ikki nuqta: (1) SSRF himoya — allowlist (eng kuchli — faqat ruxsat etilgan), ichki IP blok, protokol cheklash, redirect tekshir (qatlamlar); (2) bulut metama'lumot (169.254.169.254) — albatta blokla (eng xavfli SSRF nishoni — IAM kalitlari — butun bulut hisobi xavfda). SSRF himoyasi murakkabroq (CSRF'dan) — chunki ko'p chetlab o'tish usuli bor (redirect, DNS rebinding, IP formatlari — 0x7f.0.0.1, [::1]). Eng ishonchli — allowlist (faqat ma'lum domenlar — qolgani rad) + bulut metama'lumotni blok + protokol cheklash. Agar server foydalanuvchi URL'iga so'rov yuborsa (rasm, webhook, import — bu xususiyatlar SSRF xavfi), bu himoyalarni qo'shing. SSRF'ni e'tiborsiz qoldirish — zamonaviy bulut ilovalarining eng katta xavflaridan.

2.6. CSRF vs SSRF (taqqoslash)

text
  CSRF vs SSRF — nomi o'xshash, mohiyati BOSHQA:

  ┌──────────────┬────────────────────────┬────────────────────────┐
  │              │ CSRF                   │ SSRF                   │
  ├──────────────┼────────────────────────┼────────────────────────┤
  │ Kim so'rov   │ Foydalanuvchi brauzeri │ Server                 │
  │ yuboradi?    │ (uning cookie'si bilan)│ (foydalanuvchi URL'iga)│
  │ Nishon       │ Sizning saytingiz      │ Ichki tizim/bulut      │
  │ Suiiste'mol  │ Foydalanuvchi cookie'si│ Server ichki kirishi   │
  │ Zarar        │ Foydalanuvchi nomidan  │ Ichki ma'lumot sizishi │
  │              │ amal (pul, parol)      │ (kalitlar, ichki API)  │
  │ Himoya       │ SameSite, CSRF token   │ Allowlist, IP blok     │
  └──────────────┴────────────────────────┴────────────────────────┘

  UMUMIY: ikkalasi ham "soxta so'rov" + "ishonchni suiiste'mol"
  FARQ: CSRF (foydalanuvchi brauzeri) | SSRF (server)

   CSRF — foydalanuvchi brauzeri so'rov (cookie); SSRF — server so'rov (ichki kirish)
   Nomi o'xshash, lekin boshqa hujum — himoyasi ham boshqa (chalkashtirma)

CSRF vs SSRF (taqqoslash) — ikki nomi o'xshash hujumni ajratish. Nomi o'xshash (ikkalasida "Request Forgery"), lekin mohiyati boshqa: (1) kim so'rov yuboradi — CSRF: foydalanuvchi brauzeri (uning cookie'si bilan); SSRF: server (foydalanuvchi bergan URL'ga); (2) nishon — CSRF: sizning saytingiz (foydalanuvchi nomidan amal); SSRF: ichki tizim/bulut (server orqali); (3) suiiste'mol — CSRF: foydalanuvchi cookie's (brauzer avtomatik qo'shadi); SSRF: server ichki kirishi (ishonchli vakil); (4) zarar — CSRF: foydalanuvchi nomidan amal (pul o'tkazish, parol o'zgartirish); SSRF: ichki ma'lumot sizishi (bulut kalitlari, ichki API); (5) himoya — CSRF: SameSite cookie, CSRF token; SSRF: allowlist, ichki IP blok. Umumiy: ikkalasi ham "soxta so'rov" + "ishonchni suiiste'mol" (CSRF — foydalanuvchi cookie ishonchini, SSRF — server ichki kirish ishonchini). Farq: CSRF — foydalanuvchi brauzeri so'rov yuboradi (sizning saytingizga); SSRF — server so'rov yuboradi (ichki resurslarga). Ikki nuqta: (1) CSRF — foydalanuvchi brauzeri so'rov (cookie), SSRF — server so'rov (ichki kirish); (2) nomi o'xshash, lekin boshqa hujum — himoyasi ham boshqa (chalkashtirma — CSRF token SSRF'ni himoyalamaydi, allowlist CSRF'ni himoyalamaydi). Bu farqni tushunish muhim (ish suhbatida ham so'rashadi — "CSRF va SSRF farqi?"). Eslab qolish: CSRF — client (foydalanuvchi) so'rov; SSRF — server so'rov. Har ikki hujum zamonaviy web'da uchraydi (CSRF — cookie auth, SSRF — URL ishlatuvchi xizmatlar), va har biri o'z himoyasini talab qiladi.

2.7. Bonus — Clickjacking (CSRF'ning "vizual" qarindoshi)

text
  CLICKJACKING — foydalanuvchini KO'RINMAS tugmani bosishga aldash:

  QANDAY: hujumchi sizning saytingizni ko'rinmas <iframe>'ga joylaydi
   ustiga jozibali "yutuqni oling" tugmasini qo'yadi (soxta qatlam)
   foydalanuvchi "yutuq" tugmasini bosadi, aslida iframe ichidagi
    haqiqiy tugmani bosadi (masalan "hisobni o'chir", "ruxsat ber")
   foydalanuvchi bilmasdan haqiqiy amalni bajaradi (o'z cookie'si bilan)

  CSRF bilan aloqasi: ikkalasi ham foydalanuvchi niyatisiz amal,
  lekin clickjacking — foydalanuvchi CHIN BOSADI (aldangan holda),
  CSRF esa — foydalanuvchi umuman bosmaydi (avtomatik so'rov).

  HIMOYA — saytingizni boshqa saytning iframe'iga joylashni taqiqlash:
   X-Frame-Options: DENY        (hech kim iframe'ga joylay olmaydi)
   X-Frame-Options: SAMEORIGIN  (faqat o'z domen iframe'lay oladi)
   CSP: frame-ancestors 'none'  (zamonaviy — X-Frame-Options o'rniga)
   CSP: frame-ancestors 'self'  (faqat o'z domen — zamonaviy variant)

   Clickjacking — ko'rinmas iframe + soxta tugma (vizual aldov)
   Himoya — X-Frame-Options yoki CSP frame-ancestors (iframe'ni taqiqla)

Clickjacking — CSRF'ga o'xshash, "vizual" hujum (bonus mavzu). Clickjacking (UI redressing) — foydalanuvchini ko'rinmas tugmani bosishga aldash. Qanday ishlaydi: (1) hujumchi sizning saytingizni (masalan bank sozlamalari sahifasi) ko'rinmas (shaffof) <iframe>'ga joylaydi; (2) uning ustiga jozibali soxta qatlam qo'yadi ("Yutuqni oling!" tugmasi); (3) foydalanuvchi soxta tugmani bosadi, lekin aslida iframe ichidagi haqiqiy tugmani bosadi (masalan "Hisobni o'chir" yoki "Ilovaga ruxsat ber"); (4) foydalanuvchi o'z cookie'si bilan haqiqiy amalni bilmasdan bajaradi. CSRF bilan aloqasi: ikkalasi ham foydalanuvchi niyatisiz amal, lekin farqi — clickjacking'da foydalanuvchi tugmani chin bosadi (aldangan holda, ko'rinmas iframe ustida), CSRF'da esa foydalanuvchi umuman bosmaydi (so'rov avtomatik yuboriladi). SameSite cookie clickjacking'ni to'smaydi (chunki so'rov o'z saytdan, iframe ichida — cookie qo'shiladi) — shuning uchun alohida himoya kerak. Himoya — saytingizni boshqa saytning iframe'iga joylashni taqiqlash: X-Frame-Options: DENY (hech kim iframe'ga joylay olmaydi) yoki SAMEORIGIN (faqat o'z domen), va zamonaviy varianti — CSP (Content-Security-Policy — 14.3) frame-ancestors 'none' yoki 'self'. Bu header'lar brauzerga "bu sahifani iframe ichida ko'rsatma" deb aytadi clickjacking to'siladi. Ikki nuqta: (1) clickjacking — ko'rinmas iframe + soxta tugma (vizual aldov, foydalanuvchi chin bosadi); (2) himoya — X-Frame-Options yoki CSP frame-ancestors (iframe'ni taqiqlash). Muhim amal sahifalarida (sozlama, to'lov, ruxsat) bu header'lar bo'lishi kerak. Ko'p framework va host (Vercel, Next.js) bu header'ni oson qo'shish imkonini beradi (next.config headers yoki middleware).

3. Sintaksis — tez ma'lumotnoma

text
CSRF SAMESITE 2.3-bob: cookie: { sameSite: "lax" yoki "strict", httpOnly, secure }
CSRF TOKEN 2.3-bob:    yashirin maydon + server tekshiruv (framework avtomatik)
CSRF ORIGIN 2.3-bob:   request.headers.get("origin") — o'z domen tekshir
SSRF ALLOWLIST 2.5-bob:ALLOWED.includes(new URL(userUrl).hostname)
SSRF IP BLOK 2.5-bob:  127.0.0.1, 10.x, 169.254.169.254 (bulut) — rad
SSRF PROTOKOL 2.5-bob: faqat http/https (file://, gopher:// rad)
CLICKJACK 2.7-bob:     X-Frame-Options: DENY | CSP: frame-ancestors 'none'

4. Batafsil misollar

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

Misol 1 — CSRF hujum misoli (2.1)

Maqsad: CSRF hujumi qanday ishlashini ko'rsatish — soxta sahifa foydalanuvchi cookie'si bilan amal qildiradi. Bu hujumni tushunish himoya uchun zarur.

html
<!--  HUJUMCHI SOXTA SAHIFASI (hacker.com/win.html) -->
<!-- Foydalanuvchi bankka kirgan (bank.com cookie bor brauzerda) -->
<h1>Tabriklaymiz! Siz yutdingiz!</h1>   <!-- chalg'itish -->

<!-- Yashirin forma — avtomatik yuboriladi: -->
<form id="csrf" action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="to" value="hujumchi_hisobi">
  <input type="hidden" name="amount" value="10000000">
</form>
<script>document.getElementById("csrf").submit();</script>
<!--  sahifa ochilganda AVTOMATIK bankka POST yuboradi -->
<!-- Brauzer bank.com COOKIE'sini AVTOMATIK qo'shadi (foydalanuvchi kirgan) -->
<!--  bank "haqiqiy foydalanuvchidan" deb 10 mln o'tkazadi! -->
text
NEGA ISHLAYDI:
1. Foydalanuvchi bank.com'ga kirgan  cookie brauzerda
2. Soxta sahifa bank.com'ga POST yuboradi
3. Brauzer QOIDA: har bank.com so'roviga bank.com cookie'ni qo'shadi
   (BOSHQA saytdan yuborilsa ham — bu brauzer dizayni)
4. Bank cookie'ni ko'rib "kirgan foydalanuvchi" deb bajaradi
 Foydalanuvchi HECH NARSA QILMADI (faqat sahifani ochdi)

Bu nima qiladi: Bu — CSRF hujumi (mexanizmni tushunish — 2.1). Hujumchi soxta sahifasi (hacker.com/win.html): tashqaridan oddiy ko'rinadi ("Tabriklaymiz, yutdingiz!" — chalg'itish), lekin ichida yashirin forma bor (action="https://bank.com/transfer" — pul o'tkazish, to = hujumchi hisobi, amount = 10 mln) va JavaScript bilan sahifa ochilganda avtomatik submit qiladi (form.submit()). Nega ishlaydi: (1) foydalanuvchi bankka (bank.com) kirgan — sessiya cookie brauzerda saqlangan; (2) foydalanuvchi hujumchi havolasini bosib, soxta sahifani ochadi (email, reklama, ijtimoiy tarmoq orqali); (3) soxta sahifa bank.com/transferga POST yuboradi; (4) brauzer qoidasi — har bank.comga ketgan so'rovga bank.com cookie'ni avtomatik qo'shadi (hatto so'rov hacker.comdan boshlangan bo'lsa ham — bu brauzer dizayni, eski xususiyat); (5) bank so'rovni oladi, cookie'ni ko'radi ("haqiqiy, kirgan foydalanuvchi"), va pul o'tkazmasini bajaradi. Natija: foydalanuvchi hech narsa qilmadi (faqat zararsiz ko'ringan sahifani ochdi), lekin 10 mln so'mi hujumchiga o'tdi. Bu CSRF'ning butun kuchi — foydalanuvchi niyatisiz, bilmasdan amal (cookie avtomatik qo'shilishidan foydalanish). Hujumchi javobni ko'rmaydi (CORS to'sadi — 2.2), lekin amal bajarilgan (pul ketdi). Bu hujumni tushunish himoyani (2.3 — SameSite, CSRF token) anglashga yordam beradi: so'rov haqiqatan bank sahifasidan kelganini tasdiqlash kerak (soxta sahifadan emas). Eski saytlar (SameSite cookie yo'q) bunga zaif edi.

Misol 2 — CSRF himoyasi (SameSite + token — 2.3)

Maqsad: CSRF'ni SameSite cookie va CSRF token bilan himoyalash. Bu zamonaviy va an'anaviy himoyaning birikmasi.

tsx
// 1. SAMESITE COOKIE (eng oson — sessiya cookie'da):
import { cookies } from "next/headers";
async function setSession(token: string) {
  const store = await cookies();
  store.set("session", token, {
    httpOnly: true,       // XSS himoya (14.2)
    secure: true,         // HTTPS
    sameSite: "lax",      //  CSRF himoya — boshqa saytdan so'rovda cookie YUBORILMAYDI
    path: "/",
  });
}
//  soxta sahifa (Misol 1) bank.com'ga POST yuborsa — sameSite="lax" cookie'ni qo'shmaydi
//    bank "kirmagan" deb rad qiladi (CSRF to'sildi)

// 2. CSRF TOKEN (qo'shimcha — kuchli; Auth.js avtomatik beradi):
// Server formaga token beradi:
const csrfToken = generateToken();   // har sessiyaga noyob, maxfiy
// <form><input type="hidden" name="csrf" value={csrfToken} />...</form>

// Server Action / Route tekshiradi:
async function transfer(formData: FormData) {
  const token = formData.get("csrf");
  if (token !== getSessionCsrfToken()) throw new Error("CSRF tekshiruv");   // soxta — token yo'q/noto'g'ri
  // ... amal (faqat to'g'ri token bilan)
}

Bu nima qiladi: Bu — CSRF himoyasi (SameSite + token — 2.3). 1. SameSite cookie (eng oson, zamonaviy): sessiya cookie'ga sameSite: "lax" bayrog'i — bu brauzerga "bu cookie'ni faqat o'z saytdan kelgan so'rovlarga qo'sh, boshqa saytdan (soxta sahifadan) kelgan so'rovga qo'shma" deydi. Natija: Misol 1'dagi soxta sahifa bank.com/transferga POST yuborsa, brauzer sameSite: "lax" tufayli sessiya cookie'ni qo'shmaydi bank "kirmagan foydalanuvchi" deb rad qiladi (CSRF to'sildi — bir bayroq bilan!). "lax" — havola bosib o'tishda (top-level navigatsiya) cookie qo'shiladi (qulay), lekin yashirin so'rovda (forma submit, img) — yo'q (CSRF to'sildi — yaxshi balans). "strict" — har doim faqat o'z saytdan (qattiqroq). Bu eng oson CSRF himoyasi (har sessiya cookie'da sameSite bo'lishi kerak). 2. CSRF token (qo'shimcha, kuchli — Auth.js avtomatik): server har formaga maxfiy, noyob token beradi (yashirin maydon), va amal bajarishda tokenni tekshiradi (token !== getSessionCsrfToken() rad). Soxta sahifada bu token yo'q (hujumchi uni bilmaydi — har sessiyaga noyob, server biladi) soxta so'rov rad etiladi (faqat haqiqiy sahifa to'g'ri token yuboradi). Demak: SameSite (default himoya — bir bayroq) + CSRF token (qo'shimcha — defense in depth). Zamonaviy frameworklar (Next.js Server Actions, Auth.js — 13.9) ikkalasini avtomatik qiladi (SameSite cookie + CSRF token — siz qo'lda kam yozasiz). Lekin tamoyilni bilish kerak (cookie auth ishlatsangiz — sameSite majburiy). Bu himoya CSRF'ni samarali to'sadi (soxta so'rov cookie/token'siz — rad).

Misol 3 — SSRF hujum va himoyasi (2.4, 2.5)

Maqsad: SSRF — server foydalanuvchi URL'iga so'rov — va allowlist himoyasi. Bu rasm/avatar yuklash kabi xususiyatda xavf.

tsx
//  ZAIF — server foydalanuvchi URL'dan rasm oladi (SSRF):
async function importAvatar(imageUrl: string) {
  const res = await fetch(imageUrl);   // foydalanuvchi URL — tekshiruvsiz!
  return res.arrayBuffer();
}
// hujumchi: imageUrl = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
//  server bulut metama'lumotga so'rov  IAM kalitlari hujumchiga (butun bulut egallandi!)

//  XAVFSIZ — allowlist + IP blok + protokol:
const ALLOWED_HOSTS = ["images.unsplash.com", "cdn.myshop.uz", "avatars.githubusercontent.com"];

async function importAvatar(imageUrl: string) {
  let url: URL;
  try { url = new URL(imageUrl); } catch { throw new Error("Noto'g'ri URL"); }

  // 1. Protokol (faqat https):
  if (url.protocol !== "https:") throw new Error("Faqat HTTPS");

  // 2. Allowlist (faqat ruxsat etilgan domen):
  if (!ALLOWED_HOSTS.includes(url.hostname)) throw new Error("Ruxsat etilmagan manba");

  // 3. (qo'shimcha) ichki IP'ni blok — agar allowlist yo'q bo'lsa:
  // if (isPrivateIP(url.hostname)) throw new Error("Ichki manzil taqiqlangan");

  const res = await fetch(url.toString(), { redirect: "error" });   // redirect rad (2.5)
  return res.arrayBuffer();
}

Bu nima qiladi: Bu — SSRF hujumi va himoyasi (2.4, 2.5 — rasm/avatar yuklash xususiyatida keng xavf). Zaif kod: server foydalanuvchi bergan URL'dan (imageUrl) rasmni tekshiruvsiz oladi (fetch(imageUrl)) — masalan "avatar URL'ini kiriting" xususiyati. Hujumchi tashqi rasm URL o'rniga http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS bulut metama'lumot — IAM kalitlari) beradi server (bulut ichida, ishonchli) o'sha URL'ga so'rov yuboradi bulut metama'lumot xizmati IAM kalitlarini qaytaradi server uni hujumchiga qaytaradi (avatar sifatida saqlaydi yoki ko'rsatadi) hujumchi bulut kalitlarini oladi (butun bulut hisobi egallandi — Capital One stsenariysi). Xavfsiz kod: (1) URL tahlil (new URL — noto'g'ri URL'ni rad); (2) protokol (url.protocol !== "https:" — faqat HTTPS — file://, http:// ichki — rad — 2.5); (3) allowlist (ALLOWED_HOSTS — faqat ruxsat etilgan domenlar: Unsplash, o'z CDN, GitHub avatarlari — qolgani rad — eng kuchli himoya — 2.5); (4) redirect rad (fetch(..., { redirect: "error" }) — hujumchi tashqi (ruxsat etilgan) URL berib, ichki URL'ga redirect qilishi mumkin — redirect'ni rad qilish — 2.5); (5) qo'shimcha — ichki IP blok (isPrivateIP — agar allowlist ishlatmasangiz). Endi hujumchi 169.254.169.254 bersa — allowlist'da yo'q rad (SSRF to'sildi). Asosiy himoya — allowlist (faqat ma'lum, ruxsat etilgan domenlar — qolgani rad). Agar server faqat ma'lum manbalardan rasm/ma'lumot olsa (CDN, GitHub), allowlist ideal (ishonchli ro'yxat). Agar har qanday URL kerak bo'lsa (kamroq holda), ichki IP blok + bulut metama'lumot blok + protokol cheklash. Rasm yuklash (URL'dan), webhook URL, RSS import, link preview — bularda SSRF xavfi (server foydalanuvchi URL'iga so'rov). Bu xususiyatlarda SSRF himoyasi (allowlist — eng yaxshi) majburiy. SSRF — zamonaviy bulut ilovasining eng katta xavflaridan (e'tiborsiz qoldirilsa — to'liq bulut egallash).

Misol 4 — Ichki IP bloklash (SSRF — 2.5)

Maqsad: Allowlist mumkin bo'lmaganda ichki IP/manzillarni bloklash — SSRF denylist himoyasi. Bu har qanday URL kerak bo'lganda.

tsx
import { promises as dns } from "dns";
import net from "net";

// Ichki/xavfli IP'larni aniqlash:
function isPrivateIP(ip: string): boolean {
  if (ip === "127.0.0.1" || ip === "::1" || ip === "localhost") return true;
  if (ip === "169.254.169.254") return true;   //  bulut metama'lumot (eng xavfli)
  const parts = ip.split(".").map(Number);
  if (parts[0] === 10) return true;                                 // 10.x.x.x
  if (parts[0] === 172 && parts[1] >= 16 && parts[1] <= 31) return true;  // 172.16-31.x
  if (parts[0] === 192 && parts[1] === 168) return true;           // 192.168.x
  if (parts[0] === 169 && parts[1] === 254) return true;           // 169.254.x (link-local)
  return false;
}

async function safeFetch(userUrl: string) {
  const url = new URL(userUrl);
  if (url.protocol !== "https:" && url.protocol !== "http:") throw new Error("Protokol");

  //  Domenni IP'ga aylantirib tekshir (DNS — domen ichki IP'ga ishora qilishi mumkin):
  const { address } = await dns.lookup(url.hostname);
  if (isPrivateIP(address)) throw new Error("Ichki manzil taqiqlangan");

  return fetch(userUrl, { redirect: "error" });
}

Bu nima qiladi: Bu — ichki IP bloklash (SSRF denylist — allowlist mumkin bo'lmaganda — 2.5). Agar server har qanday tashqi URL'dan ma'lumot olishi kerak bo'lsa (allowlist mumkin emas — masalan link preview, RSS), unda ichki/xavfli manzillarni bloklash kerak. isPrivateIP funksiyasi xavfli IP'larni aniqlaydi: 127.0.0.1/::1/localhost (server'ning o'zi — ichki xizmatlar), 169.254.169.254 (bulut metama'lumot — eng xavfli — IAM kalitlari), va xususiy tarmoq diapazonlari (10.x, 172.16-31.x, 192.168.x — ichki tarmoq — boshqa serverlar, DB). safeFetch: (1) protokol tekshir (http/https); (2) eng muhim — domenni IP'ga aylantirib tekshir (dns.lookup — chunki hujumchi evil.com domenini ichki IP'ga (169.254.169.254) ishora qildirishi mumkin — DNS orqali — shuning uchun domen nomini emas, haqiqiy IP'ni tekshirish kerak); (3) agar IP ichki bo'lsa — rad (isPrivateIP). Bu allowlist'dan zaifroq (denylist — barcha yomonni oldindan bilish kerak — yangi chetlab o'tish usullari paydo bo'lishi mumkin — IPv6, IP formatlari 0x7f..., DNS rebinding), lekin har qanday URL kerak bo'lganda yagona variant. Eng muhim nuqta — domen nomini emas, DNS lookup orqali haqiqiy IP'ni tekshirish (evil.com 169.254.169.254 ishora qilsa, domen "tashqi" ko'rinadi, lekin IP ichki — IP'ni tekshirish kerak). Va redirect: "error" (redirect orqali chetlab o'tishni to'sish). Demak SSRF himoyasi: allowlist (eng yaxshi — Misol 3) yoki denylist (ichki IP blok — bu Misol — har qanday URL kerak bo'lganda). Production'da ikkalasi birga (allowlist + IP blok — defense in depth) yoki maxsus SSRF himoya kutubxonasi/proxy (yanada ishonchli — DNS rebinding, IPv6 holatlari). SSRF himoyasi nozik (ko'p chetlab o'tish usuli) — shuning uchun allowlist afzal (oddiy, ishonchli).

Misol 5 — Next.js'da CSRF (Server Actions — 2.3)

Maqsad: Next.js Server Actions va Auth.js CSRF'ni qanday avtomatik hal qilishini ko'rsatish. Bu zamonaviy frameworkda himoyaning soddaligi.

tsx
// Next.js SERVER ACTIONS — CSRF himoyasi AVTOMATIK:
"use server";
export async function transfer(formData: FormData) {
  const session = await auth();
  if (!session) throw new Error("Kiring");
  //  Next.js Server Actions:
  //   - faqat POST (GET emas — 2.2)
  //   - Origin header tekshiradi (so'rov o'z saytdan — avtomatik)
  //   - SameSite cookie (Auth.js — sessiya)
  //  soxta saytdan Server Action chaqirib bo'lmaydi (CSRF to'silgan)
  await db.account.update({ /* pul o'tkazish */ });
}

// AUTH.JS — sessiya cookie SameSite + CSRF token (avtomatik):
// auth.ts'da cookie default: sameSite: "lax", httpOnly: true, secure (production)
//  CSRF himoyasi sozlashsiz ishlaydi (framework boshqaradi)

// ESLATMA — Route Handlers (API)'da qo'lda ehtiyot bo'lish kerak:
// agar cookie-auth API yozsangiz  SameSite + Origin tekshir (Server Actions kabi avtomatik emas)
text
XULOSA (Next.js CSRF):
 Server Actions — CSRF avtomatik (Origin tekshir + POST + SameSite)
 Auth.js — sessiya cookie SameSite/CSRF token avtomatik
 Route Handlers (cookie-auth) — qo'lda (SameSite + Origin)
 Token auth (Bearer header) — CSRF tabiiy yo'q (14.6)

Bu nima qiladi: Bu — Next.js'da CSRF himoyasi (Server Actions + Auth.js — avtomatik — 2.3). Zamonaviy frameworklar CSRF'ni ko'p qismini avtomatik hal qiladi (siz kam ish qilasiz). Server Actions 13.5-bob: "use server" funksiya CSRF'dan avtomatik himoyalangan — chunki Next.js Server Actions: (1) faqat POST (GET emas — 2.2 — GET amal qilmaydi); (2) Origin header tekshiradi (so'rov o'z saytdan kelganini avtomatik — soxta saytdan kelsa rad); (3) SameSite cookie (Auth.js sessiya). Natija: soxta saytdan Server Action'ni chaqirib bo'lmaydi (CSRF to'silgan — qo'lda hech narsa qilmadingiz). Auth.js 13.9-bob: sessiya cookie'ni default sameSite: "lax", httpOnly: true, secure (production) bilan o'rnatadi, va CSRF token'ni avtomatik beradi — CSRF himoyasi sozlashsiz ishlaydi (framework boshqaradi). Eslatma — Route Handlers (API — 13.6)'da qo'lda ehtiyot: agar siz cookie-auth bilan API yozsangiz (Server Action emas), CSRF himoyasi avtomatik emas — sameSite + Origin tekshir qo'shishingiz kerak (Server Actions kabi avtomatik emas). Va token auth (Bearer header — 14.6): token cookie'da emas, Authorization header'da bo'lsa — CSRF tabiiy yo'q (brauzer header'ni avtomatik qo'shmaydi — soxta sayt header qo'sha olmaydi). Xulosa: Next.js'da CSRF asosan avtomatik (Server Actions — Origin/POST/SameSite, Auth.js — cookie SameSite/token) — modern framework ishlatsangiz, CSRF kam tashvish. Lekin: cookie-auth Route Handlers'da qo'lda (SameSite + Origin), va tamoyilni bilish kerak (nega himoyalangan). Bu — zamonaviy frameworkning afzalligi (xavfsizlik default — lekin qaerda avtomatik, qaerda qo'lda — bilish kerak). Token auth (14.6 — keyingi bob) CSRF'ni tabiiy yo'qotadi (header — cookie emas).

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

1) Cookie

text
 sameSite yo'q (CSRF — Misol 1)
 sameSite: "lax"/"strict" (CSRF to'siq — Misol 2)

2) GET amal

text
 GET /delete?id=5 (CSRF oson — 2.2)
 POST/DELETE amal uchun (GET faqat o'qish)

3) Server URL fetch

text
 fetch(userUrl) tekshiruvsiz (SSRF — Misol 3)
 allowlist + IP blok + protokol (Misol 3, 4)

4) Bulut metama'lumot

text
 169.254.169.254 bloklanmagan (SSRF — kalit sizishi)
 albatta blok (Misol 4)

5) DNS tekshir

text
 faqat domen tekshir (DNS ichki IP'ga — Misol 4)
 DNS lookup  haqiqiy IP tekshir

6) Redirect

text
 redirect kuzatiladi (allowlist chetlab o'tish)
 redirect: "error" (rad — Misol 3)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — SameSite cookie yo'q

Sababi: CSRF himoyasi yo'q (Misol 1). Yechimi: sameSite: "lax"/"strict" (Misol 2).

Xato 2 — GET amal qiladi

Sababi: REST buzilgan (CSRF oson — 2.2). Yechimi: amal — POST/PUT/DELETE.

Xato 3 — Server foydalanuvchi URL'iga tekshiruvsiz so'rov

Sababi: SSRF (Misol 3). Yechimi: allowlist + IP blok.

Xato 4 — Bulut metama'lumot bloklanmagan

Sababi: 169.254.169.254 ochiq (Misol 4). Yechimi: albatta blok.

Xato 5 — Domen tekshir, IP emas

Sababi: DNS ichki IP'ga ishora (Misol 4). Yechimi: DNS lookup IP tekshir.

Xato 6 — CSRF va SSRF chalkashtirish

Sababi: nomi o'xshash 2.6-bob. Yechimi: CSRF (client/cookie), SSRF (server/ichki) — boshqa himoya.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Auth (13.9, 14.6): SameSite cookie, token auth (CSRF himoya).
  • Server Actions 13.5-bob: CSRF avtomatik (Origin/POST).
  • Route Handlers 13.6-bob: cookie-auth — qo'lda CSRF; URL fetch — SSRF.
  • OWASP 14.1-bob: SSRF = A10; CSRF (eski A8).
  • XSS 14.2-bob: XSS CSRF token'ni o'g'irlashi mumkin (birga — kuchliroq).
  • CSP 14.3-bob: frame-ancestors — clickjacking himoya 2.7-bob.
  • Cloud (10-QISM): bulut metama'lumot (SSRF nishoni — IAM).
  • Webhook/import: SSRF xavfi (server URL'ga so'rov).
  • CORS 13.6-bob: CSRF'dan farqli — CORS soxta saytga javobni o'qishni to'sadi (so'rov yuborishni emas — shuning uchun CORS o'zi CSRF himoyasi emas).

8. Eng yaxshi amaliyotlar (best practices)

  • SameSite cookie (lax/strict — CSRF — Misol 2).
  • GET amal qilmasin (REST — 2.2).
  • Token auth (Bearer header — CSRF tabiiy yo'q — 14.6).
  • SSRF allowlist (faqat ruxsat etilgan domen — Misol 3).
  • Bulut metama'lumot blok (169.254.169.254 — Misol 4).
  • DNS lookup IP tekshir (domen emas — Misol 4).
  • redirect: "error" (SSRF chetlab o'tish — Misol 3).
  • Framework CSRF (Server Actions/Auth.js avtomatik — Misol 5).
  • Protokol cheklash (https — SSRF — Misol 3).
  • Clickjacking himoya (X-Frame-Options/CSP frame-ancestors — 2.7).
  • CSRF ≠ SSRF (boshqa himoya — 2.6).

9. Amaliy loyiha: "CSRF va SSRF Himoyasi"

CSRF va SSRF himoyasini real ilovada mustahkamlash.

Maqsad

Ilova qur (cookie-auth + URL import xususiyati) — CSRF va SSRF'dan himoyalangan.

Talablar (requirements)

  1. SameSite cookie: sessiya himoya (Misol 2).
  2. CSRF token: amal so'rovlarga (yoki framework avtomatik — Misol 5).
  3. GET faqat o'qish: amal POST/DELETE 2.2-bob.
  4. SSRF allowlist: avatar/rasm URL import (Misol 3).
  5. Ichki IP blok: 169.254.169.254 va xususiy (Misol 4).
  6. DNS tekshir: haqiqiy IP (Misol 4).
  7. Protokol/redirect: https + redirect rad (Misol 3).
  8. Test: CSRF (soxta forma) + SSRF (ichki URL) sinab ko'r.
  9. Framework: Server Actions CSRF (Misol 5).
  10. Audit: cookie auth + URL fetch joylarini tekshir.

Maslahatlar (hint)

  • SameSite (Xato 1).
  • Amal POST (Xato 2).
  • SSRF allowlist (Xato 3).
  • Bulut blok (Xato 4).
  • DNS IP (Xato 5).

"Tayyor" mezonlari (acceptance criteria)

  • SameSite cookie.
  • CSRF himoya (token/framework).
  • GET amal qilmaydi.
  • SSRF allowlist.
  • Ichki IP/bulut blok.
  • CSRF/SSRF payload ishlamaydi (test).

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

10. Xulosa va keyingi bobga ko'prik

Bu bobda CSRF va SSRF'ni chuqur o'rgandik:

  • CSRF 2.1-bob; CSRF ta'siri 2.2-bob; CSRF himoya (SameSite/token — 2.3); SSRF 2.4-bob; SSRF himoya (allowlist/IP blok — 2.5); CSRF vs SSRF 2.6-bob; Clickjacking (X-Frame-Options/CSP — 2.7).

Endi siz CSRF'ni (SameSite cookie, CSRF token) va SSRF'ni (allowlist, ichki IP blok, bulut metama'lumot) oldini olasiz. Ikki nomi o'xshash, lekin mohiyati boshqa hujum (client/cookie vs server/ichki).

Keyingi bob — 14.5-bob: Autentifikatsiya va parol xavfsizligi. Hujum turlarini bildik; endi autentifikatsiya xavfsizligini chuqur ko'ramiz: parol xeshlash (bcrypt/argon2 — nega va qanday), parol siyosati (kuchli parol), brute force himoyasi (rate limit, lockout), 2FA (ikki bosqichli), sessiya xavfsizligi, va keng auth xatolari. Bu — OWASP A07 (Auth Failures) va har ilovaning poydevori.

Foydalanilgan rasmiy/ishonchli manbalar

  • OWASP — "Cross-Site Request Forgery (CSRF)", "Server-Side Request Forgery (SSRF)"
  • OWASP Cheat Sheet Series — "CSRF Prevention Cheat Sheet", "SSRF Prevention Cheat Sheet"
  • OWASP Top 10 — A10:2021 (SSRF); CSRF (avvalgi A08 turkumida)
  • MDN Web Docs — SameSite cookies, Set-Cookie, X-Frame-Options, Clickjacking
  • W3C / MDN — Content Security Policy: frame-ancestors direktivi
  • Next.js hujjatlari — Server Actions xavfsizligi (Origin tekshiruvi), next.config headers
  • Node.js hujjatlari — dns.lookup, URL, fetch (redirect: "error")
  • Capital One breach (2019) — bulut metama'lumot orqali SSRF (real hodisa tahlili)
  • PortSwigger Web Security Academy — CSRF va SSRF bo'yicha amaliy laboratoriyalar

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
14.4-bob: CSRF va SSRF — Wisar