IDOR — application user taqdim etgan obyekt identifikatoridan foydalanib, ayni userga tegishli bo‘lmagan resource’ga accessni yetarli tekshirmaganda yuzaga keladigan access control zaifligi. To‘liq nomi Insecure Direct Object Reference.
IDOR odatda boshqa userning profilini, orderini, faylini, invoice’ini yoki admin obyektini IDni almashtirish orqali olish, o‘zgartirish yoki o‘chirish imkonini beradi.
Direct object reference
URL yoki request ichida resource ID ochiq ko‘rsatilishi mumkin:
/orders/150
/files/abc123
/users/42
Bu o‘z-o‘zidan zaiflik emas.
Zaiflik server 150 orderga current user kirishga haqlimi, degan tekshiruvni bajarmaganda paydo bo‘ladi.
Horizontal privilege escalation
Oddiy user boshqa oddiy userning resource’iga kiradi.
Masalan:
user A → user B invoice’i
Har ikkala user bir xil rolga ega, ammo ownership boshqacha.
Bu horizontal access control buzilishi.
Vertical privilege escalation
Oddiy user administrator yoki yuqori huquqli resource’ga murojaat qiladi.
Masalan, admin endpoint IDsi yoki role qiymatini o‘zgartirish.
Bu vertical privilege escalation.
IDOR ko‘pincha object-level authorization bilan bog‘liq.
Read IDOR
Server boshqa userga tegishli ma’lumotni qaytaradi:
Faqat sensitive fieldlarni yashirish emas, butun resource accessi tekshiriladi.
Write IDOR
Attacker boshqa user resource’ini update qiladi.
Masalan:
- delivery address;
- email;
- status;
- permission;
- file nomi;
- payment method.
Write operation read’dan ham kuchliroq zarar keltirishi mumkin.
Delete IDOR
Resource ID almashtirilib boshqa userning fayli yoki recordi o‘chiriladi.
Soft delete bo‘lsa ham availability va business integrity buziladi.
Delete uchun ownership bilan birga operation-specific permission tekshiriladi.
UUID himoya emas
Sequential integer o‘rniga UUID ishlatish IDni taxmin qilishni qiyinlashtiradi.
Ammo ID leak, log, link, browser history yoki boshqa API orqali olinishi mumkin.
Unpredictable ID authorizationning o‘rnini bosmaydi.
Object-level authorization
Har requestda server quyidagilarni tekshiradi:
- current principal;
- tenant;
- resource owner;
- role;
- resource state;
- requested action;
- delegated permission.
Frontend tugmani yashirishi security control emas.
Backend qaror chiqaradi.
Query darajasida cheklash
Resource avval global ID bilan olinib, keyin ownership tekshirilishi mumkin.
Yaxshiroq usul ko‘pincha queryning o‘zida scope qo‘shish:
id = requested_id
AND owner_id = current_user
Shunda ruxsatsiz obyekt application memory’siga ham kelmaydi.
Multi-tenant tizim
Tenant ID har query va relationshipda hisobga olinadi.
Faqat global object_id bilan qidirish boshqa tenant data’sini qaytarishi mumkin.
Composite key yoki mandatory tenant scope ishlatiladi.
Background job va admin tool ham tenant chegarasiga rioya qiladi.
Nested resource
/users/15/orders/200
ko‘rinishida bo‘lsa order haqiqatan user 15ga tegishlimi tekshiriladi.
Faqat user va orderning alohida mavjudligi yetarli emas.
Relationshipning o‘zi authorization qismidir.
File va object storage
Database row himoyalangan, ammo file URL public yoki taxmin qilinadigan bo‘lsa IDORga o‘xshash data leak yuz beradi.
- private bucket;
- server-side authorization;
- qisqa signed URL;
- tenant prefix;
- download audit
bilan boshqariladi.
Mass assignment bilan aloqa
User request body’ga owner_id, role yoki tenant_id yuborib resource ownershipni o‘zgartirishi mumkin.
Serializer faqat ruxsat etilgan fieldlarni qabul qiladi.
Server security-sensitive fieldlarni current contextdan o‘zi belgilaydi.
Error javobi
Ruxsatsiz resource uchun 403 yoki mavjud emasdek 404 qaytarilishi mumkin.
Bu enumerationni kamaytiradi, ammo ichki audit haqiqiy sababni bilishi kerak.
Status tanlovi authorization siyosatiga bog‘liq.
Test
IDOR testlari:
- boshqa user IDsi;
- boshqa tenant;
- read, update, delete;
- nested resource;
- file download;
- batch endpoint;
- GraphQL node;
- mobile API;
- eski version endpoint;
- background export
holatlarini qamrab oladi.
Har endpoint uchun object-level authorization tekshiriladi.
Audit
Sensitive obyektga access:
bilan audit qilinadi.
Ko‘p ketma-ket IDga request enumeration indikatori bo‘lishi mumkin.
Batch endpoint
Bir requestda ko‘p ID qabul qiladigan endpoint har bir obyekt uchun authorization tekshiradi. Faqat birinchi ID yoki umumiy collection permissionini tekshirish yetarli emas. Natijada ruxsatsiz itemlar jim chiqarib tashlanishi yoki butun request rad etilishi policy bilan belgilanadi.
GraphQL
GraphQL global node ID, nested resolver va field-level access orqali object authorization muammosiga duch kelishi mumkin. Parent resolver ruxsatli bo‘lsa ham child relationship boshqa tenant data’sini qaytarmasligi kerak. Har resolver context va ownershipni hisobga oladi.
Export
Background export user requestidan keyin worker tomonidan bajariladi. Worker current user va tenant contextini job payloadda xavfsiz saqlaydi. Faqat file IDga tayanib boshqa user exportini yuklashga ruxsat berilmaydi.
Admin istisnosi
Administrator barcha resource’ga kira olsa ham bu explicit policy bo‘ladi va audit qilinadi. “Admin bo‘lishi mumkin” degan taxmin bilan umumiy authorizationni o‘chirib qo‘yish oddiy user requestiga ham ta’sir qilishi mumkin.
Indirect reference
Clientga internal database ID o‘rniga vaqtinchalik mapping yoki public ID berilishi mumkin. Bu enumerationni kamaytiradi, ammo server mappingdan keyin ham authorization tekshiradi. Indirect reference qo‘shimcha himoya, asosiy access control emas.
Bog‘liq tushunchalar
Insecure Direct Object Reference, Broken Access Control, Authorization, Horizontal privilege escalation, Vertical privilege escalation, Multi-tenancy, Ownership, UUID, API security