🛡️ OWASP Top 10 API: To‘liq tahlil va himoya choralari

Hozirgi raqamli asrda mobil ilovalar, veb-platformalar va IoT qurilmalarining ko‘pchiligi API (Application Programming Interface) orqali ishlaydi. API’lar orqali tizimlar bir-biri bilan muloqot qiladi, foydalanuvchi ma’lumotlarini uzatadi va biznes jarayonlarini avtomatlashtiradi. Ammo bu qulaylik bilan birga kiberxavfsizlik tahdidlari ham oshib bormoqda.

🛑 API1:2023 – Broken Object Level Authorization

(Obyekt darajasidagi avtorizatsiyaning buzilishi)

1. Zaiflik mohiyati (BOLA nima?)

«Broken Object Level Authorization» — bu API foydalanuvchisi unga tegishli bo‘lmagan obyektga (resursga) ruxsatsiz kirishga urinayotganida avtorizatsiya tekshiruvlarining noto‘g‘ri yoki umuman yo‘qligi tufayli yuzaga keladigan zaiflikdir.

🧠 Oddiy misol:

GET /api/user/12345/orders

Agar foydalanuvchi user_id=12345 unga tegishli bo‘lmasa, lekin tizim bu so‘rovni tekshirmasdan javob qaytaraversa — bu BOLA zaifligi hisoblanadi.

🚨 2. Nega bu xavfli?

  • 👀 Ma’lumotlar sizib chiqishi: Foydalanuvchi boshqa shaxsga oid maxfiy ma’lumotlarga kira oladi.
  • 🏴‍☠️ Identifikatsiya buzilishi: Hackerlar “Insecure Direct Object Reference” (IDOR) hujumlar orqali resurslar ustidan to‘liq nazoratni qo‘lga olishi mumkin.
  • 📉 Tashkilotning ishonchliligi pasayadi, GDPR kabi qonunchiliklar buziladi.

🎯 3. Ko‘pincha qanday holatlarda uchraydi?

HolatTavsif
🔓 Avtorizatsiya yo‘qFoydalanuvchi har qanday object_id bilan so‘rov yubora oladi
🧩 Static ID manzillariURLda IDlar o‘zgaruvchan bo‘lsa, ularni «guess» qilish oson
🧪 Test yetarli emasQA paytida boshqa foydalanuvchilar resurslari bilan test qilinmagan
⛔ Authni faqat frontendda qilishBarcha tekshiruvlar serverda bo‘lishi shart!

4. Tahlil qilish (Pentester yoki DAST uchun)

  • 🔍 Foydalanuvchi A ning tokeni bilan foydalanuvchi B ning obyektlariga so‘rov yuboriladi
  • 🔁 Resurslar bo‘yicha GET, PUT, DELETE so‘rovlar yuborib tekshiriladi
  • 🔢 “Insecure Direct Object Reference” orqali id=1, id=2, id=3… ketma-ketlik sinab ko‘riladi
  • 🛠 Burp Suite, Postman yoki OWASP ZAP orqali test qilinadi

🛡️ 5. Himoya choralari (Tavsiya etilgan yechimlar)

✅ Server tomonida qat’iy avtorizatsiya:

Har bir resursga murojaat qilgan foydalanuvchining ushbu resursga egalik huquqi bor-yo‘qligi tekshirilishi kerak.

pythonКопироватьРедактироватьif request.user.id != object.owner_id:
    return HttpResponseForbidden()

🔐 Ob’ektga oid huquqlarni aniqlash:

  • Har bir API endpointda foydalanuvchi huquqi tekshirilishi kerak.
  • Masalan: “/user/1234/profile” chaqiruvini faqat user_id=1234 bo‘lgan foydalanuvchi amalga oshira olishi kerak.

🧩 Ob’ekt identifikatorlarini yashirish:

  • Integer ID o‘rniga UUID yoki tokenlar ishlatish.
  • Masalan: /api/user/b314-98ae-b1f2/orders — bu user_id=2 ga qaraganda topish qiyinroq.

🔐 Rolga asoslangan kirish nazorati (RBAC):

  • Har bir foydalanuvchi turi (user, admin, manager) uchun resurslar chegaralangan bo‘lishi kerak.

🧪 Avtomatlashtirilgan testlar:

  • Har bir yangi API funksiyasi uchun negative tests yozing (ya’ni boshqa foydalanuvchi tokeni bilan test).
  • Security Unit Tests ishlatish foydali.

6. Himoya qilishda foydali vositalar:

VositaMaqsad
🔐 OAuth 2.0 / JWTHar bir so‘rovda kimligini aniq belgilash
🧪 OWASP ZAPZaifliklarni avtomatik skanerlash
🧪 Burp Suite ProManzilli avtorizatsiya teshiklarini aniqlash
🛠 Postman TestsRegression testlar yordamida auth ni tekshirish
🧩 Spring Security / Express middlewareAuth modullarini mustahkamlash uchun frameworklar

Xulosa

Asosiy fikrlarTavsiya
Har bir API so‘rovida foydalanuvchining huquqi tekshirilsin✅ Backendda tekshiruv
Obyekt ID ni yashiring yoki murakkab qiling✅ UUID ishlating
Ruxsat tekshiruvi faqat frontendga emas, backendga yuklansin✅ Serverda auth
Test, test va yana test✅ Negative testlar shart!

🛡️ API2:2023 – Broken Authentication (Buzilgan autentifikatsiya)

Broken Authentication – bu API foydalanuvchilarning shaxsini noto‘g‘ri tekshirganida yoki autentifikatsiya jarayonida xavfsizlik talablari buzilganda yuzaga keladigan zaiflikdir. Bu holatda tajovuzkor (hacker) boshqa foydalanuvchining sessiyasiga noqonuniy kirishi yoki tizimni foydalanuvchi sifatida aldab kirishi mumkin.

Potensial xavflar:

  • Foydalanuvchilarning shaxsiga kirish (identity theft)
  • Hisoblarni buzish (account takeover)
  • Xizmatdan foydalanish huquqini egallash (privilege escalation)
  • API ni kirish nuqtasi sifatida ishlatib, boshqa tizimlarga hujum qilish

Buzilgan autentifikatsiya belgilari:

  • Foydalanuvchi sessiyasi doimiy yoki avtomatik ravishda yangilanmaydi
  • Parol siyosati kuchsiz (masalan, 123456 yoki abc123 qabul qilinadi)
  • 2FA (ikki bosqichli autentifikatsiya) mavjud emas
  • Autentifikatsiya tokenlari yashirin emas yoki brauzerda noto‘g‘ri saqlanadi
  • Login urinishlari soniga cheklov yo‘q

Himoya choralar:

🔐 Parol va kirish siyosati

  • Kuchli parol siyosatini joriy qiling: minimal uzunlik, murakkablik (raqam, katta harf, belgilar)
  • Parolni hashing bilan saqlang (bcrypt, Argon2 kabi algoritmlar)
  • Parolni ochiq holda logga yozmang yoki tashqi tizimga yubormang

🔐 Sessiya va token boshqaruvi

  • Har bir login uchun yangi sessiya yarating
  • JWT tokenlar uchun maxfiy kalitlarni saqlashda ehtiyot bo‘ling
  • Tokenlarga muddati tugash (expiration) belgilang
  • Token revokatsiya tizimini ishlab chiqing (masalan, foydalanuvchi logout qilganda token bekor qilinsin)

📲 2FA (Ikki faktorli autentifikatsiya)

  • Foydalanuvchilar uchun 2FA imkoniyatini taqdim eting (SMS, email, authenticator app)

⚠️ Brute Force hujumlariga qarshi himoya

  • Login urinishlarini cheklash (rate limiting)
  • Har bir muvaffaqiyatsiz login urinishini logga yozing va monitoring qiling
  • Captcha dan foydalaning

🔐 API kalitlarini boshqarish

  • API kalitlari va tokenlar maxfiy bo‘lishi kerak
  • Ularni ochiq kodga qo‘shmang, ayniqsa frontendda
  • Har bir foydalanuvchiga alohida API kaliti yarating, va ularni audit qilinadigan tarzda boshqaring

Tavsiya etilgan texnologiyalar va kutubxonalar:

MaqsadTavsiya etilgan vosita
Parol hashingbcrypt, Argon2
2FAGoogle Authenticator, Authy, Twilio Verify
Token boshqaruviOAuth 2.0, OpenID Connect
Brute force himoyarate limiting (Nginx, Express-rate-limit, Cloudflare Rules)
JWT bilan ishlashjsonwebtoken (Node.js), pyjwt (Python), jjwt (Java)

Test qilish (security testing) usullari:

  • OWASP ZAP yoki Burp Suite orqali autentifikatsiya jarayonlarini skanerlash
  • Foydalanuvchi hisoblarini buzish urinishlari (brute force, credential stuffing)
  • Token manipulation va replay attack testlari

Broken Authentication — bu API xavfsizligi uchun eng jiddiy tahdidlardan biri. To‘g‘ri parol siyosati, kuchli token boshqaruvi, ikki bosqichli autentifikatsiya va hujumlarga qarshi aktiv monitoring orqali bu zaiflikni sezilarli darajada kamaytirish mumkin.

API3:2023 – Ob’ekt xossalari darajasidagi buzilgan avtorizatsiya (Broken Object Property Level Authorization)

“Broken Object Property Level Authorization” — bu API foydalanuvchining ma’lum bir ob’ektning xossalariga (masalan, isAdmin, salary, internalNotes) kirishini noto‘g‘ri tekshirish oqibatida yuzaga keladigan xavfsizlik muammosidir.

Bu zaiflik foydalanuvchiga tegishli bo‘lmagan, hassasiy yoki boshqaruvga oid ma’lumotlarga ruxsatsiz kirish imkonini beradi.

Faraz qilaylik sizda quyidagi API endpoint mavjud:

PATCH /api/users/123
{
   "name": "Ali",
   "isAdmin": true
}

Oddiy foydalanuvchi bu so‘rov orqali o‘z ismini o‘zgartirish o‘rniga, isAdmin kabi muhim xossani ham tahrirlashi mumkin bo‘lib qoladi — agar server ushbu xossaning ruxsat darajasini alohida tekshirmasa.

Natija: Oddiy foydalanuvchi o‘zini administratorga aylantirib yuboradi.

🔍 Qanday aniqlanadi?

  • API so‘rovlaridagi kiruvchi JSON ni tahlil qilish
  • Har bir xossaning ruxsat tekshiruvini testlash (manual yoki avtomatlashtirilgan)
  • Foydalanuvchi sessiyasi bilan noto‘g‘ri xossalarni yuborib sinash

🛡️ Himoya choralari:

✅ 1. Server tarafda qat’iy ruxsat tekshiruv:

Har bir foydalanuvchiga faqat tegishli xossalarni tahrirlash huquqi berilishi kerak. Foydalanuvchi yuborgan JSON tarkibi ko‘r-ko‘rona qabul qilinmasligi lozim.

✅ 2. “White-list” (ruxsat etilgan xossalar) yondashuvi:

Serverga kelgan so‘rovdan faqat oldindan ruxsat berilgan xossalarni qabul qiling:

const allowedFields = ['name', 'email'];
const filteredUpdate = pick(req.body, allowedFields);

✅ 3. Ma’lumotlar qatlamini izolyatsiya qilish:

DTO (Data Transfer Object) yordamida API xabarlari bilan ichki model orasida abstraktsiya qatlami yarating. Bu noxush xossalarning yuborilishining oldini oladi.

✅ 4. Foydalanuvchi roli asosida ruxsatni boshqarish:

Har bir foydalanuvchi roliga mos policy yoki middleware ishlating:

if (req.user.role !== 'admin' && req.body.isAdmin !== undefined) {
   return res.status(403).send("Forbidden");
}

✅ 5. Testlar va kod audit:

  • Unit testlar yordamida nojo‘ya xossalarni yuborish sinovdan o‘tkazilsin.
  • Static Application Security Testing (SAST) vositalari yordamida kodda avtorizatsiya qatlamlarini tahlil qiling.

Test holati (penetration test misoli):

Oddiy foydalanuvchi sifatida quyidagi so‘rovni yuboring:

PATCH /api/users/456
{
   "name": "Jamshid",
   "isAdmin": true
}

Agar javobda isAdmin haqiqatan true bo‘lib qolsa — tizimda API3 zaifligi bor.

API3:2023 zaifligi — API’larda ruxsat tekshiruvining nafaqat ob’ektga, balki xossalar darajasida ham amalga oshirilishi zarurligini ko‘rsatadi. Bu zaiflikni bartaraf qilish — sizning tizimingizga kirib keluvchi har bir foydalanuvchining imkoniyatlarini qat’iy chegaralashni talab etadi.

🔒 API4:2023 – Unrestricted Resource Consumption

➤ Cheklanmagan Resurs Sarfi: API xavfsizligidagi jiddiy tahdid

Unrestricted Resource Consumption – bu API foydalanuvchining (ko‘pincha yomon niyatli foydalanuvchining) so‘rovlariga cheklovlar qo‘yilmagani natijasida serverdagi hisoblash, saqlash, tarmoqli yoki boshqa resurslarning ortiqcha iste’mol qilinishiga sabab bo‘ladigan zaiflikdir. Bu zaiflik natijasida xizmat rad etilishi (DoS) yoki tizimning sekinlashishi yuzaga keladi.

Misollar orqali tushuntirish

📍 Misol 1: Limitlarsiz fayl yuklash

Foydalanuvchiga fayl yuklashga ruxsat berilgan, lekin hajm va son bo‘yicha hech qanday cheklov yo‘q. Xaker 1TB hajmdagi faylni ketma-ket yuborib, server diskini to‘ldirib qo‘yadi.

📍 Misol 2: Cheklanmagan sahifa so‘rovlar (pagination)

API endpoint’lari (/api/products?page=1) orqali sahifalash amalga oshiriladi, lekin maksimal sahifa o‘lchami (limit) belgilanmagan. Xaker ?limit=100000 deb yuboradi — bu esa katta hajmdagi ma’lumotni qayta ishlashga olib keladi.

📍 Misol 3: Oqimli (streaming) so‘rovlar

Tizimda real-time oqimli ma’lumotlar mavjud va xaker bir nechta ulanishlar ochib, barchasini cheklanmagancha ochiq qoldiradi. Bu tarmoqni yoki protsessorni band qiladi.

🛡️ Himoya choralari

✅ 1. So‘rovlar limitini belgilash (Rate limiting)

Har bir foydalanuvchi uchun IP/mijozga asoslangan so‘rov tezligini cheklang. Masalan:

  • 100 so‘rov/min
  • 1000 so‘rov/kun

✅ 2. Resurs o‘lchami va davomiyligiga cheklovlar

  • Yuklanayotgan fayl hajmini cheklang (masalan, maksimal 10 MB)
  • API response limitlarini belgilang (limit=50)
  • Streaming sessiyalarni vaqt yoki hajm bo‘yicha to‘xtating

✅ 3. Autentifikatsiya va avtorizatsiyani shart qiling

Agar imkon bo‘lsa, API so‘rovlarini autentifikatsiya talab qiladigan qilib sozlang. Noaniq foydalanuvchilarning so‘rovlarini cheklang.

✅ 4. Qo‘shimcha xavfsizlik darajasi: CAPTCHA yoki tokenlar

  • CAPTCHA yoki CSRF tokenlar orqali avtomatlashtirilgan so‘rovlar oldini oling

✅ 5. Monitoring va loglash

  • Har bir endpoint uchun so‘rov statistikalarini kuzatib boring
  • Noan’anaviy faoliyat (masalan, millionlab so‘rovlar) aniqlansa — avtomatik blok

“Unrestricted Resource Consumption” – tashqi ko‘rinishda oddiy tuyuladigan, lekin tizimga jiddiy zarar yetkazuvchi zaiflikdir. Foydalanuvchining so‘rovlariga vaqt, hajm, tezlik va sessiya asosida qat’iy cheklovlar qo‘yish, bu tahdidga qarshi eng samarali choradir.

🔐 API5:2023 – Broken Function Level Authorization

Ushbu zaiflik foydalanuvchilarning funktsiyalar (API endpointlar) darajasida noto‘g‘ri ruxsat bilan foydalanishiga imkon beradi. Ya’ni, foydalanuvchi o‘ziga tegishli bo‘lmagan yoki yuqori darajadagi API funksiyalarni chaqirishi va ulardan foydalanishi mumkin bo‘ladi.

Misol:

Oddiy foydalanuvchi quyidagi so‘rovni yuboradi:

GET /api/v1/admin/users

Agar bu endpoint faqat admin foydalanuvchilar uchun mo‘ljallangan bo‘lsa-yu, tizim uni oddiy foydalanuvchi tomonidan ham bajarishga ruxsat bersa — bu Broken Function Level Authorization hisoblanadi.

Sabablari:

  • Foydalanuvchi rollariga asoslangan ruxsat tizimining yo‘qligi.
  • Faoliyat (funktsiya) darajasida tekshiruv yo‘qligi (faqat foydalanuvchi darajasida bo‘ladi).
  • «Security through obscurity» — endpoint yashirin deb, uni xavfsiz deb noto‘g‘ri hisoblash.

🚨 Xavflar:

  • Maxfiy ma’lumotlarga noqonuniy kirish.
  • Ma’lumotlarni o‘zgartirish yoki o‘chirish.
  • Tizimni buzib kirish va buzilishlarga olib kelish.
  • Audit izlarini yashirish (admin endpointlar orqali).

🛡️ Himoya choralari:

✅ 1. Rollar asosida ruxsat nazorati (RBAC) ni joriy qilish

  • Har bir endpointda foydalanuvchi roli tekshirilsin: pythonКопироватьРедактироватьif user.role != "admin": return 403 Forbidden

✅ 2. Faoliyatga asoslangan ruxsat (ABAC yoki FLAC)

  • Foydalanuvchi qanday harakat qilishga ruxsatli — aniq belgilang.
  • Masalan, CRUD (Create, Read, Update, Delete) harakatlar ajratilsin.

✅ 3. Frontendga ishonmang

  • Faqat UI (foydalanuvchi interfeysi) darajasida cheklash bilan cheklanib qolmang.
  • API darajasida mustahkam ruxsat mexanizmi bo‘lishi shart.

✅ 4. Audit va monitoring

  • Noqonuniy API chaqiruvlarni aniqlash uchun loglar yuriting va monitoringni yoqing.

✅ 5. Minimal ruxsat siyosati

  • Har bir foydalanuvchi faqat o‘z faoliyatiga tegishli endpointlarga kirishi kerak.

Test qilish:

  1. Turli rollar bilan turli endpointlarga so‘rov yuboring.
  2. Admin endpointlarga oddiy foydalanuvchi bilan kirishga urining.
  3. Penetration testda ruxsat darajalari buzilishi mumkinmi — tekshirib chiqing.

“Broken Function Level Authorization” – juda xavfli va ko‘p uchraydigan zaiflikdir. U API foydalanuvchisining rolidan qat’i nazar, noto‘g‘ri yoki yuqori darajadagi funksiyalarga kirishiga olib keladi. Bu esa butun tizim xavfsizligiga tahdid tug‘diradi. Shuning uchun, har bir API chaqirig‘ida faoliyatga va ro‘lga asoslangan ruxsatni tekshirish juda muhimdir.

🛡️ API6:2023 – Maxfiy foydalanuvchi harakatlariga cheklanmagan kirish (Unrestricted Access to Sensitive Business Flows)

«Unrestricted Access to Sensitive Business Flows» Bu zaiflik foydalanuvchi platformada bajarishi kerak bo‘lgan muhim amallar (masalan, buyurtma berish, to‘lov qilish, chegirma olish va boshqalar) ustidan nazorat yetarlicha o‘rnatilmaganda yuzaga chiqadi. Ya’ni, tizim bu amallarga kim va qachon kirishini tekshirib turmaydi.

Natijada, yovuz niyatli foydalanuvchi avtomatlashtirilgan hujumlar orqali bu jarayonlardan (aksariyat hollarda savdo yoki pul bilan bog‘liq bo‘lganlardan) foyda olishga harakat qiladi.

Misollar:

  • Botlar chegirma kodlarini ommaviy tarzda avtomatik qo‘llab xarid qilishadi.
  • Foydalanuvchilar bir necha daqiqa ichida yuzlab soxta buyurtma yuborishadi.
  • To‘lov tizimining zaifligidan foydalanib, cheksiz tranzaktsiyalar amalga oshirishga uriniladi.

Potensial xavf:

Oddiy foydalanuvchilarning platformadagi tajribasi buziladi (misol: sayt sekin ishlaydi yoki ishga yaramaydi).olatlar uchun mo‘ljallangan bo‘ladi, lekin noto‘g‘ri API dizayni natijasida hammaga ochiq qoladi.

Moliyaviy zarar.

Resurslarning keraksiz ishlatilishi.

Ishlab chiqarishdagi nosozliklar.

Real hayotdagi misol

Tasavvur qiling, bir e-commerce saytda quyidagi API mavjud:

GET /api/v1/coupon/generate

Agar ushbu endpoint autentifikatsiyadan o‘tmagan yoki maxsus ruxsatnoma talab qilmaydigan bo‘lsa, xaker quyidagicha skript orqali promo-kodlarni cheksiz ishlab chiqara oladi:

for i in range(1000):
    response = requests.get("https://site.com/api/v1/coupon/generate")
    print(response.text)

Bu kompaniya uchun katta yo‘qotishlarga olib keladi.

🛡️ Himoya choralar:

  1. Harakatlar ustidan nazorat o‘rnating:
    • Har qanday muhim jarayon uchun autentifikatsiya va avtorizatsiyani talab qiling.
    • Foydalanuvchi amal bajarishga haqli ekanligini har doim tekshirib boring.
  2. Rate limiting (chegaralash) qo‘llang:
    • Bir foydalanuvchi ma’lum vaqt ichida necha marta amal bajarishini cheklang.
  3. Botlarga qarshi himoya tizimlari:
    • CAPTCHA, device fingerprinting, va foydalanuvchi xatti-harakatlarini kuzatish orqali avtomatlashtirilgan harakatlarni bloklang.
  4. Monitoring va alertlar:
    • Noyob va g‘ayritabiiy foydalanuvchi harakatlarini avtomatik aniqlab, xabar beradigan tizim yarating.
  5. Frontendga ishonmang:
    • Kirishni faqat frontendda cheklamang. Backend (API) ham har doim tekshiruvlardan o‘tkazishi kerak.

🔐 API7:2023 – Server Side Request Forgery (SSRF)

(Server tomonda noto‘g‘ri so‘rov yuborilishi)

SSRF – bu xujum turi bo‘lib, xaker foydalanuvchi nomidan emas, balki serverning o‘zidan boshqa ichki yoki tashqi manbalarga soxta (yolg‘on) so‘rovlar yuborishga erishadi.

Masalan: API serveringiz foydalanuvchi tomonidan yuborilgan URLni avtomatik ravishda chaqirsa, xaker bu imkoniyatdan foydalanib, serverni ichki tarmoqdagi (masalan, http://localhost, http://127.0.0.1, http://internal-api) resurslarga so‘rov yuborishga majburlashi mumkin.

🎯 Real hayotdagi misol:

Tasavvur qiling, sizda rasm URL manzilini kiritish orqali avtomatik yuklab oluvchi API mavjud (GET /download?url=https://example.com/photo.jpg). Xaker bu yerga quyidagidek so‘rov yuboradi:

GET /download?url=http://localhost:8080/admin

Natijada, sizning serveringiz ichki admin sahifasiga murojaat qiladi va bu ma’lumotlar foydalanuvchiga qaytarilishi mumkin.

Potensial xavflar:

  • 🔓 Ichki tizimlar haqida maxfiy ma’lumotlar ochilishi
  • 🕵️‍♂️ Ichki tarmoqlarni skanerlash imkoniyati
  • 💥 Ichki xizmatlarga DoS hujumi qilish
  • 🧨 Yashirin ma’lumotlar sızib chiqishi (config, token, auth cookies)

🛡️ Himoya choralar:

✅ 1. Kiruvchi URL’larni qat’iy nazorat qilish:

  • Faqatgina ruxsat etilgan (whitelist) domenlarga ruxsat bering.
  • localhost, 127.0.0.1, 169.254.x.x, internal.* kabi man etilgan (blacklist) IP/manzillarni bloklang.

✅ 2. DNS-resolving’ni cheklang:

  • URL’larni DNS orqali tekshirganda ichki tarmoqqa oid IP-larga resolvelanishiga yo‘l qo‘ymang.

✅ 3. Tashqi so‘rovlar uchun alohida xizmat (proxy) qo‘llang:

  • So‘rov yuborishni maxsus filtrlangan xizmat orqali yo‘naltiring.

✅ 4. So‘rov turini cheklang:

  • Faqat kerakli metodlarga ruxsat bering (masalan, faqat GET, POST emas).
  • Fayl turi va javob hajmini cheklang.

✅ 5. Ichki ma’lumotlarni javobda chiqarmang:

  • Har qanday server javobida ichki xizmatlar yoki IP manzillar aks etmasligi kerak.

Test qilish uchun vositalar:

  • 🛠 Burp Suite – SSRF so‘rovlarini sinash va trafikni tahlil qilish.
  • 🧾 SSRFmap – avtomatlashtirilgan SSRF hujum vositasi.
  • 🔍 curl, Postman, httpie – qo‘lda so‘rov yuborish va javoblarni tekshirish.

SSRF zaifligi, API serverlar foydalanuvchi yuborgan URL so‘rovlariga ishonib, ularni bevosita chaqirgan hollarda yuzaga chiqadi. Bu esa ichki tarmoqdagi maxfiy resurslar, xizmatlar yoki konfiguratsiyalarni ochib qo‘yadi.

🧩 Himoya qilish uchun eng muhim qadam — kiruvchi URL’larni qat’iy nazorat qilish va tashqi so‘rovlar ustidan to‘liq monitoring o‘rnatishdir.

🛡️ API8:2023 – Xavfsizlik noto‘g‘ri sozlanganligi (Security Misconfiguration)

Security Misconfiguration» — ya’ni xavfsizlikning noto‘g‘ri sozlanishi — API (ilova dasturlash interfeysi) laridagi keng tarqalgan zaiflik bo‘lib, noto‘g‘ri yoki yetarli darajada sozlanmagan xavfsizlik parametrlaridan kelib chiqadi. Bunday xatoliklar API foydalanuvchilariga keraksiz ma’lumotlarni ko‘rsatib qo‘yishi, tashqi foydalanuvchilarga ichki tizimlar haqida ortiqcha ma’lumot berishi yoki autentifikatsiya va avtorizatsiya jarayonlarini aylanib o‘tishga imkon yaratadi.

🧯 Zaiflik qanday paydo bo‘ladi?

  • 📤 API foydalanuvchilarga debug (nosozlikni aniqlash) ma’lumotlarini ko‘rsatib qo‘yadi (masalan: stack trace, server haqida texnik tafsilotlar).
  • 🔓 API endpointlar uchun keraksiz ochiq portlar, xizmatlar yoki xavfsizlik devorlarining yo‘qligi.
  • 🔐 Avtorizatsiya siyosatlari etishmasligi yoki noto‘g‘ri sozlanganligi.
  • 📑 API’lar uchun kerakli CORS siyosatlari noto‘g‘ri bo‘lishi (masalan, hamma domenlarga ruxsat berilishi).
  • 📦 Standart konfiguratsiyalarni o‘zgartirmasdan ishlatish (masalan, default parollar, ochiq admin interfeyslar).

🎯 Real hayotdagi misol:

Tasavvur qiling, bir veb-xizmatda API orqali ishlovchi foydalanuvchining profili chaqiriladi:

GET /api/v1/user/profile

Lekin noto‘g‘ri sozlangan xavfsizlik tufayli quyidagilar ochiqlanadi:

{
  "user_id": 1345,
  "username": "admin",
  "password_hash": "$2a$12$Dg...",
  "db_connection": "mongodb://admin:123456@db.prod.local",
  "debug_info": {
    "stack_trace": "com.api.error.NullPointerException at line 42",
    "environment": "prod"
  }
}

Bu holatda foydalanuvchi admin foydalanuvchi haqida keraksiz ma’lumotlar, bazaga ulanish rekvizitlari va ichki server haqida tafsilotlarni ko‘rib turibdi — bu esa juda jiddiy xavf.

🔐 Himoya choralari:

  1. ✅ Minimal ma’lumotni ko‘rsatish: Foydalanuvchiga faqat kerakli ma’lumotni ko‘rsating. Ichki texnik tafsilotlar, stack trace yoki muhit (environment) ma’lumotlarini chiqarishdan saqlaning.
  2. 🔐 CORS siyosatini sozlang: API’ga faqat ishonchli domenlardan kirishga ruxsat bering.
  3. 🧹 Default sozlamalarni o‘zgartiring: Admin interfeyslarni yopish, default foydalanuvchilarni o‘chirish, standart portlarni almashtirish.
  4. 🔍 Avtomatlashtirilgan skanerlar bilan tekshiruv: Masalan, OWASP ZAP yoki Burp Suite yordamida xavfsizlik sozlamalarini tahlil qiling.
  5. 🧱 WAF (Web Application Firewall) va xavfsizlik qatlamlarini joriy eting.
  6. 🚫 Debug rejimni ishlab chiqarish muhitida o‘chirib qo‘ying.
  7. 🗂️ Yaxshi hujjatlashtirish: API konfiguratsiyasi va xavfsizlik siyosatlarini aniq belgilab qo‘ying.

«Security Misconfiguration» — oddiy xatolik kabi tuyulgan bo‘lsada, u orqali tajovuzkorlar butun API arxitekturasiga hujum qilishi mumkin. Har bir API endpoint xavfsizligini alohida ko‘rib chiqish, foydalanuvchilarga ko‘rsatiladigan ma’lumotlarni nazorat qilish va muntazam auditlar bu xavfni kamaytirishda muhim rol o‘ynaydi.

API9:2023 – Noto‘g‘ri Inventarizatsiyani Boshqarish (Improper Inventory Management)

Ushbu zaiflik API interfeyslarining, versiyalarining va bog‘liq komponentlarning to‘liq va aniq ro‘yxatini yuritmaslik natijasida yuzaga keladi. Tashlab ketilgan (deprecated) yoki sinov uchun mo‘ljallangan API-lar ishlab chiqarish muhitida faol bo‘lib qolishi mumkin va bu esa hujumchilarga hujum nuqtalarini topishda imkon yaratadi.

🎯 Asosiy muammo

  • API versiyalarining chalkashligi yoki noto‘g‘ri belgilanishi.
  • Foydalanilmayotgan, lekin ochiq holatda qolgan API endpointlar.
  • Ichki API-larni ishlab chiqarish muhitiga chiqarib qo‘yish.
  • API katalogi (API inventory) va hujjatlarining yo‘qligi yoki eskirganligi.

⚠️ Real tahdidlar

  • 🔍 Hujumchilar tashlab ketilgan API versiyalarini aniqlab, ulardagi eski zaifliklardan foydalanishi mumkin.
  • 🔓 Ichki (internal) yoki test API-lar orqali maxfiy ma’lumotlarga kirish imkoni paydo bo‘ladi.
  • 🚨 API-lar ustidan to‘liq nazorat yo‘qligi texnik qarorlar va xavfsizlik siyosatlariga ziddilik keltiradi.

🛡️ Himoya choralari

1. To‘liq API inventarizatsiyasi yarating

  • Har bir API endpoint, versiya, foydalanish holati va egasi bo‘yicha ma’lumotlar yuritilsin.
  • Ularni hujjatlarda va monitoring vositalarida saqlang.

2. Versiyalarni boshqaring

  • Har bir API versiyasining yaroqlilik muddati va qo‘llab-quvvatlash darajasini belgilab boring.
  • Eski yoki xavfsizligi kafolatlanmagan versiyalarni faoliyatdan to‘liq chiqarib tashlang.

3. Ichki va test API-larni ajrating

  • Test va dev muhitlar uchun API-lar hech qachon ishlab chiqarish (production) muhitida ishlatilmasin.
  • Ichki API-lar tashqi foydalanuvchilar uchun yopiq bo‘lishi kerak.

4. Monitoring va aniqlash vositalarini joriy eting

  • API-ning faoliyat holatini kuzatuvchi tizimlar (API gateway, WAF, SIEM) orqali harakatlarni nazorat qiling.
  • Foydalanilmayotgan endpointlar avtomatik aniqlanib, o‘chirilishi kerak.

5. Hujjatlarni muntazam yangilab boring

  • Har bir API uchun texnik va xavfsizlik hujjatlari mavjud bo‘lishi shart.
  • O‘zgarishlar kiritilganda hujjatlar avtomatik tarzda yangilanadigan tizimlardan foydalaning.

«Improper Inventory Management» — ko‘pincha e’tibordan chetda qoladigan, ammo jiddiy tahdidlarni yuzaga keltiruvchi zaifliklardan biridir. API-larning to‘liq nazorati yo‘q bo‘lsa, hatto eng yaxshi xavfsizlik mexanizmlari ham o‘z kuchini yo‘qotadi. Shuning uchun sizning API arxitekturangizda qat’iy nazorat, aniq hujjatlar va monitoring vositalari bo‘lishi muhim.

🛑 API10:2023 – API’larning xavfli ishlatilishi (Unsafe Consumption of APIs)

Bu zaiflik API xizmatlaridan (ichki yoki tashqi) noto‘g‘ri va xavfsizlik talablariga javob bermaydigan tarzda foydalanilganda yuzaga keladi. Ko‘plab ishlab chiquvchilar uchinchi tomon (third-party) API yoki xizmatlardan foydalanayotganda ularning ishonchliligini, xavfsizlik holatini, autentifikatsiya darajasini tekshirmay qo‘shib yuborishadi. Bu esa xavfsizlikka jiddiy tahdid tug‘diradi.

Tasavvur qiling, siz biror to‘lov API’dan foydalanmoqdasiz. Agar bu API noto‘g‘ri sozlangan yoki javoblarni tekshirishsiz qabul qilsa, tajovuzkor yolg‘on to‘lovlarni amalga oshirishi yoki soxta tranzaksiyalarni tasdiqlashi mumkin. Bundan tashqari, ichki API’lar orasidagi bog‘lanish ham faqat IP manzilga asoslangan ishonchga qurilgan bo‘lsa, bu katta xatodir.

Potensial xatarlar

  • Ma’lumotlarning sizib ketishi (Data Leakage)
  • Soxta javoblar asosida noto‘g‘ri qarorlar qabul qilinishi
  • Xizmatdan foydalanish holatining buzilishi (DoS)
  • Supply chain (ta’minot zanjiri) orqali ichkariga zararli kod kirib kelishi

🛡️ Himoya choralari

1. API’larni sinchiklab tekshiring

  • Har qanday tashqi yoki ichki API integratsiyasidan oldin xavfsizlik tahlilini bajaring.
  • API’ning rasmiy hujjatlari va xavfsizlik protokollariga rioya qiling.

2. Whitelisting va autentifikatsiya

  • Faqat ishonchli IP yoki domenlardan foydalanishga ruxsat bering.
  • OAuth 2.0, JWT kabi zamonaviy autentifikatsiya usullarini qo‘llang.

3. Fail-Safe mexanizmlar

  • Agar tashqi API javob bermasa, tizim xavfsiz holatda ishlashni davom ettirsin.
  • Har bir API chaqiruvga time-out, retry va fallback strategiyalarini belgilang.

4. Input va Output’ni tekshirish

  • API’dan kelayotgan barcha javoblar validatsiyadan o‘tkazilsin.
  • X especially: JSON injektsiya, XSS va boshqa zararli kodlar oldini oling.

5. Rate Limiting va Throttling

  • Haddan tashqari foydalanishni cheklang.
  • Microservice’lar orasida cheklovlar qo‘llanilsin.

6. Monitoring va Logging

  • API chaqiruvlar doimiy monitoringda bo‘lishi kerak.
  • Noma’lum yoki shubhali faoliyatlar haqida ogohlantirish tizimi yarating.

API’lardan foydalanishda nafaqat texnik, balki strategik yondashuv ham muhim. Har bir tashqi yoki ichki xizmat integratsiyasi – bu sizning himoya devoringizda yangi eshik ochish bilan tengdir. Shuning uchun, har bir eshik ishonchli qulflangan, himoyalangan va kuzatuvda bo‘lishi lozim.