IDOR ve Bozuk Erişim Kontrolü: Kimlik Doğrulama Yetmez, Yetkilendirme Şart

IDOR (Insecure Direct Object Reference), bir kullanıcının geçerli bir oturumla kendisine ait olmayan bir kaynağa erişmesidir. Klasik örnek: hesap?id=1023 adresindeki numarayı 1024 yapınca başkasının faturasını görmek. Saldırgan parola kırmaz, oturum çalmaz; sadece bir tanımlayıcıyı değiştirir. IDOR, “Bozuk Erişim Kontrolü” (Broken Access Control) ailesinin en yaygın üyesidir ve OWASP Top 10’da bu kategori uzun süredir üst sıralardadır.

Kimlik doğrulama ≠ yetkilendirme

İki kavram sık karıştırılır:

• Kimlik doğrulama (authentication): “Sen kimsin?” — kullanıcının giriş yapmış olması.
• Yetkilendirme (authorization): “Bunu yapmaya/görmeye hakkın var mı?” — istenen kaynak üzerinde iznin olması.

IDOR, kimlik doğrulamanın doğru ama yetkilendirmenin eksik olduğu yerde ortaya çıkar. Kullanıcı giriş yapmıştır; ancak sunucu, istenen id’nin gerçekten o kullanıcıya ait olup olmadığını kontrol etmez.

Nasıl tespit edilir?

• Öngörülebilir tanımlayıcılar: Ardışık sayısal id’ler (1023 → 1024) manipülasyona davetiyedir.
• Her yerdeki id’ler: Yalnız adres çubuğunda değil; gizli form alanlarında, PATCH /api/orders/1024 gibi API çağrılarında, JSON gövdelerinde de olur.
• Yatay ve dikey erişim: Yatay (başka bir eşdeğer kullanıcının verisi) ve dikey (normal kullanıcının admin işlevine erişmesi) — ikisi de bu ailededir.

Pratik test: iki ayrı test hesabı açın (A ve B). A’nın oturumuyla giriş yapıp B’ye ait bir kaynağın id’sini isteyin. B’nin verisi geliyorsa IDOR vardır.

Önleme: nesne düzeyinde yetkilendirme

Kök çözüm, her kaynak erişiminde sahiplik/yetki kontrolü yapmaktır:

1. Sunucuda, oturumdaki kullanıcıya göre doğrulayın. İstemciden gelen id’ye güvenmeyin; “bu sipariş gerçekten oturum sahibinin mi?” sorusunu her seferinde sunucuda sorun.
2. Mümkünse kaynağı oturumdan türetin. “Kendi faturalarım” için WHERE user_id = oturum.kullanici şeklinde sorgulayın; id’yi doğrudan güvenilir girdi olarak almayın.
3. Merkezî bir yetkilendirme katmanı kullanın. Kontrolü tek tek uç noktalara dağıtmak, birini unutmaya yol açar; ortak bir kapıdan geçirin.
4. Öngörülemez tanımlayıcılar (UUID) yardımcı olur ama tek başına yeterli değildir. Tahmini zorlaştırır; yine de asıl koruma yetkilendirmedir.
5. Reddi varsayılan yapın. Yetki açıkça verilmediyse erişim reddedilmeli.

Neden otomatik araçlar bunu zor bulur?

IDOR, iş mantığına bağlı olduğu için jenerik tarayıcıların gözden kaçırdığı bir sınıftır: bir yanıtın “yetkisiz” olduğunu anlamak, uygulamanın kime neyin ait olduğunu bilmeyi gerektirir. Bu yüzden IDOR testinde, iki farklı hesabın birbirinin kaynağına erişip erişemediğini karşılaştıran kontrollü denemeler değerlidir.

Özet

IDOR, giriş yapmış bir kullanıcının bir tanımlayıcıyı değiştirerek başkasının verisine ulaşmasıdır ve kökü eksik yetkilendirmedir. Çözüm net: her kaynak erişiminde, oturumdaki kullanıcının o kaynağa gerçekten yetkili olduğunu sunucuda doğrulayın; reddi varsayılan yapın; mümkünse kaynağı oturumdan türetin.

Kaynaklar: OWASP: Broken Access Control (A01:2021), OWASP Authorization Cheat Sheet, CWE-639.

IDOR gibi yetkilendirme zafiyetleri iş mantığına bağlıdır. CyberTestify’ın aktif doğrulama paketi, keşfedilen uç noktalarda kontrollü yetki testleri çalıştırır — dış yüzeyinizi değerlendirin.