IDOR: login qilgan — ruxsat berilgan degani emas

Oldingi darsda brauzer yuborgan so'rovni o'zgartirishni o'rgandik. Endi o'sha ko'nikma bilan bitta savol beramiz: so'rovdagi ID'ni boshqasiga almashtirsam nima bo'ladi?

Ko'p hollarda — hech narsa bo'lmaydi, chunki server tekshiradi. Lekin juda ko'p hollarda siz birovning hisobini, buyurtmasini yoki hujjatini ochib o'tirgan bo'lasiz. Bu — IDOR, va u OWASP'ning API uchun tuzgan ro'yxatida birinchi o'rinda turadi.

Bu darsdan keyin siz ruxsat tekshiruvi yo'q joyni topa olasiz va uni Django'da to'g'ri yopa olasiz.

Buzilgan taxmin#

Bu darsda ikkita taxminni sinaymiz. Birinchisi — asosiysi:

"Foydalanuvchi login qilgan. Demak, ruxsati bor."

Bu ikkita butunlay boshqa savolni bitta deb o'ylashdan kelib chiqadi:

• Autentifikatsiya (authentication) — sen kimsan?
• Avtorizatsiya (authorization) — senga shu narsaga tegishga ruxsat bormi?

@login_required birinchi savolga javob beradi, ikkinchisiga emas. Va dasturchining tasavvurida birinchisi ikkinchisini o'z ichiga oladi — chunki u o'z brauzerida faqat o'z ma'lumotini ko'radi.

Ikkinchi taxmin esa birinchisining yamog'i sifatida tug'iladi:

"ID'ni taxmin qilib bo'lmaydi, demak xavfsiz."

Shuning uchun ketma-ket raqam o'rniga GUID qo'yiladi. Lekin yashirish — himoya emas. Bugun ID'ni taxmin qila olmaysiz; ertaga u boshqa sahifada, logda, share-havolasida yoki API javobida oshkor bo'ladi. Beshta labning uchtasi aynan shu haqida.

Atamalar#

Nazariya: tekshiruv qayerda turishi kerak#

Zaif kodning qolipi doim bir xil:

# Zaif: obyekt so'ralgan ID bo'yicha olinadi, egasi so'ralmaydi
@login_required
def order_detail(request, order_id):
    order = get_object_or_404(Order, pk=order_id)
    return render(request, "order.html", {"order": order})

@login_required bor — ya'ni tasodifiy odam kira olmaydi. Lekin login qilgan har qanday odam istalgan buyurtmani ko'ra oladi. Tekshiruv "kimsan" bosqichida to'xtab qolgan.

Ikki tekshiruvni zanjir sifatida ko'ring — IDOR ikkinchisi yo'q joyda tug'iladi:

So'rov ──► [Autentifikatsiya]  ──► [Avtorizatsiya]  ──► Javob
           kim yubordi?             nimaga ruxsat?
           @login_required          ← BU YERDA TUSHIB QOLADI
           ✓ bor                      ✗ yo'q  ──►  IDOR

@login_required birinchi darvozani qo'yadi, lekin ikkinchisi — "bu obyekt shu foydalanuvchiniki mi?" — ochiq qoladi. Zanjir birinchi halqada to'xtaydi.

Amaliyot#

Bu lab eng oddiy holat: tekshiruv umuman yo'q. Admin paneli menyuda ko'rinmaydi, lekin /robots.txt uni oshkor qiladi — sayt botlarga "bu yerga kirmang" deb yozadi va shu bilan odamga "bu yerda nimadir bor" deb aytadi. Yashirish himoya emas, birinchi marta shu yerda ko'rinadi.

Bu — IDOR'ning eng toza ko'rinishi. Server sizni sessiyadan taniydi (authentication), lekin qaysi hisobni ko'rsatishni manzildan oladi va ular bir xil odamning ekanini tekshirmaydi (authorization yo'q). Kim ekaningiz bilan nimaga tegayotganingiz bog'lanmagan.

Mana shu lab kursning eng muhim saboqlaridan birini beradi: yashirish himoya emas. GUID qo'yish ID'ni taxmin qilishni qiyinlashtiradi, lekin zaiflikni yo'qotmaydi. ID bugun blog postida, ertaga logda, indamasdan API javobida yoki share-havolasida oshkor bo'ladi. Tekshiruv o'rniga yashirishga tayangan har qanday himoya vaqt masalasi.

IDOR faqat ?id= da emas. Har qanday so'rovdagi qiymat obyektni to'g'ridan-to'g'ri ko'rsatsa — fayl nomi, hujjat raqami, buyurtma kodi — va server egasini tekshirmasa, bu o'sha zaiflik. Nomlanishi boshqa, sababi bir xil.

Bu lab avvalgilaridan farq qiladi: bu yerda ruxsat bor, lekin u noto'g'ri narsaga bog'langan — HTTP metodiga. Dasturchi "admin amali POST bilan keladi" deb o'ylagan va tekshiruvni metodga osgan. Ruxsat tekshiruvi kim va nimaga haqida bo'lishi kerak; qanday haqida emas.

Nima ishlamaydi va nega#

"Frontendda tugmani yashirsam yetadi." Admin tugmasini faqat adminlarga ko'rsatish — ko'rinishni o'zgartiradi, ruxsatni emas. Tugma yo'q bo'lsa ham so'rov manzili o'sha joyda turadi va Burp uni to'g'ridan yuboradi. Frontend — qulaylik, himoya emas.

"GUID qo'ysam taxmin qila olmaydi." 3-lab shuni yiqitdi: ID bir joyda yashirin bo'lsa, boshqa joyda oshkor. Yashirish tekshiruvni almashtira olmaydi.

"@login_required qo'ydim-ku." U faqat kimligini tekshiradi. Login qilgan har qanday odam — jumladan hujumchi ham — o'sha tekshiruvdan o'tadi. Yetishmayotgani nimaga tegishi mumkinligi.

Endi yopamiz#

IDOR'ning yechimi bitta jumlaga sig'adi: obyektni ID bo'yicha emas, egasi bo'yicha oling. Ya'ni so'rovni "shu ID'li buyurtmani ber" emas, "shu foydalanuvchining shu ID'li buyurtmasini ber" deb qo'ying.

# Zaif: har qanday login qilgan odam istalgan buyurtmani ko'radi
@login_required
def order_detail(request, order_id):
    order = get_object_or_404(Order, pk=order_id)
    return render(request, "order.html", {"order": order})

# To'g'ri: so'rov o'zi egalikni cheklaydi — begona ID 404 bo'ladi
@login_required
def order_detail(request, order_id):
    order = get_object_or_404(Order, pk=order_id, user=request.user)
    return render(request, "order.html", {"order": order})

Bitta user=request.user — begona buyurtma endi "topilmadi" bo'lib qaytadi. Diqqat qiling: 403 emas, 404. "Bu senga tegishli emas" degan 403 ham obyekt borligini tasdiqlaydi; 404 esa hech narsa oshkor qilmaydi.

DRF'da xuddi shu qoida get_queryset da yashaydi:

class OrderViewSet(viewsets.ModelViewSet):
    serializer_class = OrderSerializer
    permission_classes = [IsAuthenticated]

    def get_queryset(self):
        # Ro'yxat ham, bitta obyekt ham shu queryset'dan olinadi —
        # begona buyurtma umuman ko'rinmaydi
        return Order.objects.filter(user=self.request.user)

5-lab boshqacha yopiladi. U egalik emas, daraja masalasi. Yechim: ruxsatni HTTP metodiga emas, amalning o'ziga bog'lang — DRF'da permission_classes, Django'da @user_passes_test yoki guruh tekshiruvi GET bo'ladimi POST bo'ladimi, baribir ishlasin.

Nazorat savollari#

1. authentication va authorization orasidagi farqni bir jumlada ayting.
2. @login_required IDOR'dan himoya qiladimi? Sababini tushuntiring.
3. Nima uchun begona obyektga 403 emas, 404 qaytarish afzal?
4. "Yashirish himoya emas" — buni 3-lab misolida tushuntiring.
5. IDOR faqat ?id= parametrida bo'ladimi? 4-labdan misol keltiring.
6. horizontal va vertical privilege escalation orasidagi farq nima?
7. 5-labda ruxsat tekshiruvi nimaga noto'g'ri bog'langan edi?
8. Nega ruxsatni har view'da qo'lda yozgandan ko'ra get_queryset da cheklash xavfsizroq?
9. get_object_or_404(Order, pk=order_id, user=request.user) qatoridagi user=request.user nimani kafolatlaydi?
10. Frontendda admin tugmasini yashirish nega yetarli emas?

Report uchun talablar#

1. Skrinshot: 2-labda id=carlos bilan olingan javob (API kaliti ko'rinsin).
2. Gipotezangiz: 3-labda GUID'ni qayerdan topdingiz va bunga qanday fikrladingiz?
3. Nima ishlamadi: beshta labdan birortasida noto'g'ri yo'ldan ketdingizmi? Nega ishlamadi?
4. Tuzatuvchi kod: o'z loyihangizdan (yoki tasavvuriy) bitta view oling, unda IDOR bo'lsin, va uni get_queryset/user= bilan yoping. Kodni oldingi va keyingi holatda keltiring.

Keyingi dars: XSS — brauzerga begona kod qanday tushadi va nega "foydalanuvchi kiritgan matn — matn emas, ehtimoliy kod".