VDP/BBP'de avlanırken daha keşif aşamasında denediğimiz o en umut veren nokta,IDOR. En başından anlaşalım. IDOR , ID değişmesi değildir; ID değişip, senin iznin olmayan veriye erişimindir.
IDOR kısaca şu demek: bir kullanıcıya ait bir veriye, kullanıcı–veri ilişkisinin kontrol edilmemesi sebebiyle erişilebiliyorsa bu IDOR'dur. Son dönemlerde ciddi manada azaldı diyenler var lakin durum öyle değildir. İDOR SADECE ŞEKİL DEĞİŞTİRDİ
Eskiden : /user?id=123
Şimdi : /api/v2/resources/4c82ae1f-f94a-4b3e-9393-a150f3f3ffc
Veyahut:
POST /orders/details { "orderId": "9f1c-82a1–4b…"
}
Sıradan ID'ler ortadan kalktı onun yerine UUID, hash, base64 kullanılmaya başlandı. ID değişimi ile yetkisiz erişim yapmanın rengi değişti ve keşif de bir hayli zorlaştı. Lakin zafiyet ortadan kalkmadı.
Bir zafiyetin İDOR sayılabilmesi için şu 3 şeyi sana açıkça vermelidir:
- Farklı kullanıcı bilgisine doğrudan veyahut dolaylı erişim sağlanmalıdır.
- Değişen değer gerçek bir değer döndürmelidir.
- ID kişisel verinin referansı olmalıdır. id=aGVtZW4gZGUgZW5jb2RlIGV0IGhlbWVu bu değer encode edildiğinde senden gizli başka bir veriye erişim sağlıyor mu ? etmiyorsa değişse bile İDOR sayılmaz. Eğer decode edildiğinde başka bir kullanıcıya ait gerçek bir veriyi referans ediyorsa, formatı ne olursa olsun bu hâlâ IDOR'dur
İDOR'da mantık şu şekilde ilerler:
1. Authentication (kimlik doğrulama)
Sen kimsin?
2. Authorization
Yetkin var mı?
3. Object ownership( Bu veri sana mı ait? / sahiplik doğrulaması)
IDOR'un ana kalbi işte burasıdır.
Sunucu bu tür görevlere hazırken ; backend kodlamada yapmış olduğu hata ile "ID varsa sal gitsin" mantığıyla çalışır. IDOR net bir zafiyettir. Ya başka özel veriye erişirsin ya da erişemezsin.
GET /api/orders/45822 şöyle bir değeri 45823 diye değiştirip başka veriye eriştiysen IDOR vardır. Lakin bu sadece bir değerle de olmaz ki çoğu zaman olmuyor da. Bazen binlerce ID denemen gerekebilir. Bunu manuel yapman elbette imkansız. Bu noktada burp gibi otomatik araçlar devreye girer.
IDOR zafiyetinin önündeki en büyük engel/UUID
Modern sistemlerde kişisel veriye verilen değer bir hayli artmış durumda. Şirket hem maddi hem de itibar olarak db de var olan veriyi canı pahasına korumaya çalışıyor. IDOR zafiyetine karşı sıklıkla kullanılan UUID tanımlayıcısı nedir? Kısaca bir göz atalım.
UUID(Universally Unique Identifier)
UUID, rastgeleye yakın üretilen ve tahmin edilmesi zor olacak şekilde tasarlanmış bir kimlik değeridir.
4c82ae1f-f94a-4b3e-9393-a150f3f3ffc Genelde şu format ile karşımıza çıkar.
Sayısal değil , sıralı değil, tahmin edilmesi zor.
Lakin bu değeri gördüğümüzde hemen " Bunun ne olduğunu anlamadım nasıl değiştirip manipüle ederim ki" diye umutsuzlanma hemen. Çünkü UUID cloude gibi bir güvenlik mekanizma değildir ki. Evet ID gizlendi lakin erişim kontrolünü yapmıyor ,kontrol hala backend'de.
UUID kullanıyor olması IDOR'u engellemez. Genelde bizleri umutsuzluğa iten şeyler şunlar.
- ID , URL'de gösterilmez
- "Güvenliymiş" hissi verir
- Test eden kişinin ilk bakışta geçmesine sebep olur.
UUID, IDOR'u çözmez; sadece gizler. Yetkilendirme yoksa UUID de işe yaramaz. Tüm mesele de Yetkilendirme değil mi zaten? UUID gözünü korkutmasın.
KISACA :IDOR'un problemi ID'nin tahmin edilebilir olması değil, doğru kişinin doğru veriye erişip erişememesinin kontrol edilmemesidir.
Zeki Kayaalp/Pentester