Bu məqaləmdə həm HackerOne-da qazandığım ilk bounty haqqında, həm də bug bounty edərkən JavaScript kodlarını analiz etməyin önəmi haqqında və bir çox başqa mövzular haqqında danışacam. Hər kəs qazanacağı ilk bounty üçün səbirsizlənir və tez bir zamanda buna nail olmaq istəyir. Mən də ilk təhlükəsizlik boşluğumu tapmağa yaxınlaşarkən buna bənzər bir hekayə yaşadım. Burp Suite proxy-ni açıb veb saytda gəzirdim və qarşıma potensial IDOR ola biləcək bir endpoint çıxdı və mən də test etmək qərarı aldım. Endpoint-i aşağıdakı kimi xəyal edə bilərsiniz: GET /api/v1/users/12345/sessions/847387429477438/info

Bu endpoint-də users-dən sonra userId, sessions-dan sonra isə sessionId gəlir. Normalda proxy-yə düşən sorğu bu idi, amma mən bu sorğunu Repeater-ə atıb test etdikdə sessions və sessionId URL-də olduğu müddətcə testlərim uğursuz olacaqdı, çünki normal olaraq öz sessionId-mi URL-də saxlayıb başqa birinə aid userId-ni URL-ə yerləşdirib test etdikdə ugurlu cavab gəlməyəcəkdi.Xoşbəxtlikdən bu session və sessionId sadəcə URL-dən silindikdə birbaşa istənilən user-in info-larını görə bilirdik. Amma bu info-lar sensitive sayılmırdı, bəzi vebsayt daxili məlumatlar idi və bunu reportlasam böyük ehtimalla Informative olaraq bağlanardı reportum.

Sessions və sessionId silindikdən sonra endpoint belə oldu: GET /api/v1/users/1234/info

Nə qədər sensitive məlumat response-da qayıtmasa da, mənim diqqətimi çəkən boş bir parametr var idi response-da. Bu parametrin adını da X-AccountId olaraq düşünə bilərik. İlk ağlıma gələn "görəsən hansısa istifadəçi üçün bu parametrdə bir dəyər varmı?" düşüncəsi oldu və dərhal userId hissəsini Burp Intruder-ə ataraq müəyyən bir aralıqda ID-ləri enumeration etməyə başladım. Qeyd edim ki, bu userId-lər ardıcıl gəlir. Və nəhayət müəyyən aralıqlarda bəzi istifadəçilərə aid X-AccountId parametrlərində token qayıtmağa başladı.

İndi isə iş daha da maraqlı hal almağa başladı, amma bu mənim ilk bug bounty təcrübəm olacağı üçün həmin an tələsdim. Bu X-AccountId parametrinin başqa bir endpoint-də nəyisə çağırdığına çox əmin idim. Amma hansı endpoint-də çalışdığını öyrənmədən birbaşa IDOR ilə digər istifadəçilərə aid X-AccountId parametrindəki token-in sızdığını bildirərək reportladım və çox keçmədən proqramdan cavab gəldi. Proqram mənə bunların sensitive olmadığını dedi, amma xoşbəxtlikdən reportu needs more info statusuna keçirdilər ki, bu da mənə ikinci bir şans yaratdı. Bunun səbəbi isə proqrama yazmışdım ki, əlavə sübuta ehtiyac qalarsa mənə bildirsinlər, yeni POC göndərim.

Needs more info statusundan sonra yenidən kompüter başına qayıtdım və bu X-AccountId parametri haqqında məlumat toplamağa başladım. Burp Suite daxil oldum, Proxy tab-ına keçdim və filter search hissəsindən proxy-yə düşən bütün JavaScript sorğularının response-unda X-AccountId parametrini axtarmağa başladım və çox keçmədən daşlar yerinə oturdu. X-AccountId parametri /getUserInfo?Key= bu endpoint-də başqa bir subdomen-də istifadə olunurdu və bu məlumatlar açıq formada JS içində yazılmışdı, elə bil sizin onu oxuyub bounty qazanmağınızı gözləyirmiş kimi :)

Mən bu endpoint-i manual olaraq axtarıb tapsam da, əslində arxa fonda BurpJSLinkFinder extension-ı da həmin linki çoxdan aşkar etmişdi.

Bug Bounty hunter-ler üçün qeyd: Hunting zamanı bu extension-ın tapdığı maraqlı endpoint-ləri sadəcə keçib getməyin, onları bir-bir analiz etməyin hər zaman böyük faydası var. Çünki bəzən saatlarla manual axtardığınız bir ipucu, extension-ın çıxardığı kiçik bir sətirdə gizlənir.

getUserInfo endpoint-i işi daha da maraqlı edirdi, çünki ortada PII məlumatların sızma riski var idi, əgər hər şey istədiyim kimi baş versəydi. JavaScript-də öyrəndiyim qədər bu endpoint body hissəsində bu məlumatları istəyirdi: UserId, SessionId, X-AccountId. Əlimdə olmayan məlumatlar isə hansı subdomen-də bu endpoint-in istifadə olunduğu və Key= dəyərinin nə olduğu idi. Key= gördüyüm an vebsayta daxil olduğumda fərqli bir endpoint-də ?Key= sorğusu düşdüyünü xatırladım və dərhal həmin sorğunu proxy-dən tapdım və Repeater-ə göndərdim. Hansı subdomen-də istifadə olunduğu da artıq ortaya çıxmışdı.

Geri qalan bu sorğunu getUserInfo endpoint-inə dəyişdirib testlərimizi həyata keçirmək idi. Qeyd etdiyimiz kimi body-də UserId, SessionId və X-AccountId parametrləri bizdən istənilirdi.SessionId düzgün yoxlanılmırdı və sadəcə parametrin olması yetərli idi, içində hansı məlumat olduğu isə yoxlanılmırdı. İlk IDOR ilə əldə etdiyimiz userId və X-AccountId-ləri body-də yerləşdirərək sorğu göndərdim və nəticədə response-da birbaşa həmin istifadəçiyə aid PII məlumatlar sızdırıldı. Bunlara (ad, soyad və bir çox vebsayt daxilindəki sensitive məlumatlar daxil idi).

Yeni tapıntım üçün proqrama cavab göndərdim və onlar da zəifliyi gözdən keçirdikdən sonra HIGH severity statusu ilə reportu triaged etdilər və $1,250 dollar mükafatlandırdılar.

Burada tək mükafatım bounty deyildi. Artıq daha səbirli olmağı və zəifliklərin dərinliyinə enməyi, JavaScript kodlarını analiz etməyin önəmini bir daha anladım və mənim üçün mükəmməl təcrübə oldu. Əgər bunun kimi məqalələrimin davam etməsini istəyirsinizsə, məqaləmə dəstək ola bilərsiniz.