IDOR Açığı
Müəllif: Rövşən Məlikov
Last updated
Müəllif: Rövşən Məlikov
Last updated
Kodlanmış ID ilə qarşılaşdıqda, ümumi kodlaşdırma sxemlərindən istifadə edərək kodlanmış ID-nin şifrəsini açmaq mümkün ola bilər.
Tətbiq hashed/randomized edilmiş ID-dən istifadə edirsə, ID-nin proqnozlaşdırıla biləcəyinə baxın. Bəzən tətbiqlər qeyri-kafi entropiya yaradan alqoritmlərdən istifadə edir və beləliklə, İD'lər diqqətlə təhlil edildikdən sonra proqnozlaşdırıla bilər.Bu halda, bu ID-lərin necə yaradıldığını təhlil etmək üçün bir neçə hesab yaratmağa çalışın. Siz digər istifadəçilərə məxsus İD'ləri təxmin etməyə imkan verəcək nümunə tapa bilərsiniz.
Başqa bir API end point'i, tətbiqin digər ictimai səhifələrində (digər istifadəçilərin profil səhifəsi və s.) və ya istinad vasitəsilə URL-də təsadüfi və ya heşlənmiş ID-ləri sızdırmaq mümkün ola bilər.
Məsələn, bir dəfə mən istifadəçilərə hashed söhbət ID-si vasitəsilə ətraflı birbaşa mesajları əldə etməyə imkan verən API end point'i tapdım. Request belə görünür:
conversation_id uzun, təsadüfi, hərf-rəqəm ardıcıllığı olduğu üçün bu, ilk baxışdan yaxşı görünür. Ancaq sonradan gördüm ki, siz sadəcə olaraq istifadəçi ID-sindən istifadə etməklə hər bir istifadəçi üçün söhbətlərin siyahısını tapa bilərsiniz!
Bu, həmin istifadəçiyə aid conversation_id'lərin siyahısını qaytaracaq. Və user_id hər bir istifadəçinin profil səhifəsində hamı üçün əlçatan olacaqdır. Buna görə də, hər hansı bir istifadəçinin mesajlarını əvvəlcə profil səhifəsində onun user_id'sini əldə edərək, sonra həmin istifadəçiyə aid conversation_id'lərinin siyahısını əldə edərək və nəhayət API end point'i /api_v1/messages vasitəsilə mesajları yükləyərək oxuya bilərsiniz!
Əgər obyekt istinad İD'ləri açıqsız görünürsə, bu obyekt İD'lərinin yaradılması və ya əlaqələndirilməsi prosesini manipulyasiya etmək üçün edə biləcəyiniz bir şeyin olub olmadığına baxın.
Tətbiq tərəfindən yaradılan sorğuda heç bir ID istifadə edilmirsə, onu sorğuya əlavə etməyə cəhd edin. İd, user_id, message_id və ya digər obyekt istinad parametrlərini əlavə etməyə çalışın və bunun tətbiqin davranışına təsir edib-etmədiyinə baxın.
Məsələn, bu sorğu bütün birbaşa mesajlarınızı göstərirsə:
Bu haqda nə düşünürsünüz? Bunun əvəzinə başqa istifadəçinin mesajlarını göstərəcəkmi?
HPP zəiflikləri (eyni parametr üçün çoxlu qiymətlər təqdim etmək) həmçinin IDOR-a səbəb ola bilər. Tətbiqlər istifadəçinin eyni parametr üçün birdən çox dəyər təqdim etməsini gözləməyə bilər və bununla siz end pointdə göstərilən giriş nəzarətindən yan keçə bilərsiniz.
Bu sorğu uğursuz olarsa:
Və ya parametrləri siyahı kimi(bu ş təqdim edin:
Bəzən IDOR-a həssas olan end pointlər bizə sızan məlumatla birbaşa cavab vermir. Onlar proqramın başqa yerə məlumat sızmasına səbəb ola bilər: exxport fayllarında, e-poçtlarda və hətta mətn xəbərdarlıqlarında.
Əgər yazdığınız sorğu metodu işləmirsə, bunun əvəzinə cəhd edə biləcəyiniz bir çox başqa üsul var: GET, POST, PUT, DELETE, PATCH…
İşlədəcəyimiz hiylə isə belədir, POST-u PUT və ya əksinə əvəz edirik: eyni giriş nəzarətləri həyata keçirilməmiş ola bilər!
Bəzən tələb olunan faylın fayl növü üzrə keçid serverin emal icazəsinə fərqli şəkildə səbəb ola bilər. Məsələn, sorğu URL-nin sonuna .json əlavə etməyə çalışın və nə baş verdiyinə baxın.
Həmişə ilk növbədə kritik funksiyalarda IDOR-ları axtarın. Həm yazmaq, həm də oxumaq əsas IDOR-lar yüksək təsir göstərə bilər.
Vəziyyəti dəyişən (yazma ilə olan) IDOR-lar, parol sıfırlama, parol dəyişikliyi, hesabın bərpası baxımından IDOR-lar çox vaxt biznesə ən yüksək təsir göstərənlər olur. (Deyək ki, “e-poçt abunə parametrlərini dəyişdirin” IDOR ilə müqayisədə.)
Vəziyyəti dəyişdirməyən (oxuma ilə olan) IDOR-lara gəldikdə, tətbiqdə həssas məlumatları idarə edən funksiyaları axtarın. Məsələn, birbaşa mesajları, həssas istifadəçi məlumatlarını və şəxsi məzmunu idarə edən funksiyaları yoxlayın. Tətbiqdə hansı funksiyaların bu məlumatdan istifadə etdiyini nəzərdən keçirin və müvafiq olaraq IDOR-ları axtarın.
