IDOR Nedir ve Neden Hâlâ Bu Kadar Yaygın?

Giriş

Hiç bir web sitesinde normalde görmemen gereken bir şeyle karşılaştın mı? Belki yanlış bir linke tıkladın, belki bir URL’yi kurcaladın. Küçük bir merak anı. Ama bazı sistemlerde bu ‘merak anı’ binlerce kişinin verisine kapı aralıyor ve sistem buna tek kelime etmiyor.

Geçenlerde internette dolaşırken TikTok LIVE platformunda keşfedilen bir IDOR vakasını okudum. Milyar kullanıcılı bir platformda bulunan bu zafiyet, bir kullanıcının kendi hesabının ötesinde kontrol kazanmasına izin veriyordu. “Zafiyet giderildi, ama soruyu sormadan edemedim: onlarca yıldır bilinen bu açık neden hâlâ kapanmıyor?”

IDOR (Insecure Direct Object Reference - Güvensiz Doğrudan Nesne Referansı) zafiyetinde, uygulama, “bu kullanıcı bu veriye erişebilir mi?” sorusunu sormayı unutuyor.

OWASP’ın 2021 güncellemesine göre bu zafiyet, Broken Access Control (Kırık Erişim Kontrolü) kategorisinin en belirgin alt türüdür ve bu kategori artık Top 10 listesinin birinci sırasında. İnanması güç olsa da, OWASP’ın analiz ettiği uygulamaların %94’ünde en az bir erişim kontrolü zafiyeti tespit edildi.

IDOR Tam Olarak Ne?

IDOR, bir uygulamanın veri tabanı kaydı, dosya, hesap veya sipariş gibi arka plandaki nesnelere kullanıcıdan gelen referansla doğrudan erişmesi ve bu erişimi kimin yaptığını sorgulamadan gerçekleştirmesi durumunda ortaya çıkar.

Şöyle düşün: sisteme giriş yaptın, her şey normal. Sonra profil sayfan şu adreste açılıyor:

GET /api/kullanici/1234/profil

Peki /api/kullanici/1235/profil adresine gidersen ne olur? Eğer uygulama sunucu tarafında “bu 1235 numaralı kullanıcı, isteği gönderen kişi mi?” diye kontrol etmiyorsa o veriye de erişebilirsin.

Burada kritik bir ayrım var: kimlik doğrulama (authentication) ile yetkilendirme (authorization) aynı şey değil. Authentication “sen kimsin?” sorusunu yanıtlar. Authorization ise “sen bunu yapabilir misin?” sorusunu. IDOR, ikincisinin eksikliğinden doğar. Sisteme giriş yapmış olmak, her şeye erişebileceğin anlamına gelmiyor — ama pek çok uygulama bunu böyle varsayıyor.

IDOR Türleri

URL ve Parametre Tabanlı

En yaygın form. Kaynak kimliği doğrudan URL’de ya da sorgu parametresinde görünür:

GET /fatura?id=9821  → kendi faturan
GET /fatura?id=9820  → başkasının faturası

JSON Body Tabanlı

Kimlik bilgisi URL’de değil, istek gövdesinde gizlidir:

POST /api/adres-guncelle
{
  "user_id": "4455",
  "adres": "Yeni Mahalle No:1"
}

user_id değerini değiştirirsen ne olur? Uygulama bunu sunucu tarafındaki oturumla çapraz kontrol etmiyorsa — başkasının adresi güncellenir.

Blind IDOR

Bu türde sunucu sana doğrudan veri döndürmez, ama arka planda bir işlem gerçekleşir. Örneğin:

DELETE /api/yorum/112

112 numaralı yorum sana ait mi kontrol edilmiyor. Sunucu başarılı yanıt döndürüyor ama o yorum başkasına aitti.

Gerçek Dünyadan Örnekler

Teorik olarak bildiğimiz şeyler, gerçek dünyadaki örneklerle çok daha çarpıcı bir şekilde ortaya çıkıyor.

Uber (2017): Araştırmacı, activateFuelCard adlı bir API uç noktasında sıralı kart ID’leri göndererek Uber sürücülerine ait UUID değerlerini toplu olarak çekebildi. UUID’ler normalde tahmin edilemez — ama yanlış uç nokta onları açık servis etti. Bu UUID’ler daha ileri saldırılar için kullanılabilir durumdaydı.

Uber Eats (2021): GraphQL uç noktasında nesne düzeyinde yetki kontrolü yapılmıyordu. Kimliği doğrulanmış herhangi bir kullanıcı, platforma kayıtlı herhangi bir restoranın satış istatistiklerini ve operasyonel verilerini çekebiliyordu.

Facebook: Güvenlik araştırmacısı Youssef Sammouda, Meta sistemlerinde IDOR ve CSRF (Cross-Site Request Forgery — Siteler Arası İstek Sahteciliği) zafiyetlerini zincirleyerek hesap devralma (account takeover) saldırıları gerçekleştirebildiğini gösterdi. Tek bir zafiyet değil, iki zafiyetin birlikte kullanımıydı bu.

Neden Hâlâ Bu Kadar Yaygın?

Bu sorunun cevabı teknik değil, zihinsel.

Otomatik araçlar IDOR zafiyetlerini tespit etmekte genellikle zorlanır. Bir SQL injection testi, veri tabanına kaçış karakteri enjekte etmeye çalışır, bunu tarayıcı saptar. Ama IDOR’u tespit edebilmek için aracın 123 numaralı faturanın kime ait olduğunu bilmesi gerekir. Hiçbir tarayıcı bu bağlamsal bilgiye sahip değil.

Authentication ≠ Authorization yanılgısı. Geliştiriciler sisteme giriş kısmını titizlikle kuruyor: çok faktörlü doğrulama (MFA), güçlü parola politikaları. Ama kullanıcı içeriye girdikten sonra “zaten doğrulandı, güvenlidir” varsayımıyla hareket ediliyor. Yetkilendirme ikinci plana atılıyor.

Modern API mimarileri risk yaratıyor. REST API’lerin /api/v1/users/{id}/invoices gibi yapıları, nesne referanslarını URL’e doğrudan eşliyor. Bu tasarım geliştirmeyi kolaylaştırıyor ama beraberinde saldırganların ID değerlerini sırayla deneyerek farklı nesneleri keşfetmesini kolaylaştırıyor.

Yazılım farklı bir yere evrildi, güvenliğe önem verilmiyor. Bakıyorsun, bir startup 6 ayda ürün çıkarıyor. Authentication var, MFA var — ama authorization? ‘Sonra bakarız’ deniyor.

Test mühendisliği geri planda kalıyor, herkes AI’a yaptırıyor. Benim gözlemime göre testler giderek otomatize ediliyor, AI araçlara devrediliyor ama IDOR gibi iş mantığı hataları bu araçların göremediği kör noktalarda yaşıyor.

Nasıl Test Edilir?

Manuel test için iki hesap yeterli. Adımlar şu şekilde:

1. İki farklı hesapla giriş yap (Kullanıcı A ve Kullanıcı B)
2. Kullanıcı A ile kimlik içeren tüm işlemleri yap — Burp Suite ile HTTP trafiğini kaydet
3. ID içeren parametreleri tespit et
4. Kullanıcı A’nın oturumuyla Kullanıcı B’ye ait ID’yi gönder
5. Yanıtı karşılaştır — 200 OK ve veri dönüyorsa zafiyet var

Burp Suite Repeater ile bu test çok hızlı yapılabiliyor:

GET /api/profil/1001 HTTP/1.1
Host: hedef.com
Cookie: session=kullanici_a_token

→ id'yi 1002 yap, gönder, yanıta bak

Büyük ölçekli API testleri için Autorize eklentisi işi yarı otomatik hale getiriyor. Düşük yetkili bir hesabın oturum bilgilerini Autorize’a tanımlıyorsun; eklenti yüksek yetkili hesabın her isteğini otomatik olarak düşük yetkili hesapla tekrarlıyor. “Bypassed!” uyarısı aldığında zafiyet var demek.

Nasıl Önlenir?

Güvenlik sistemi tasarlarken sadece ‘kim girebilir?’ sorusunu sormak yetmiyor. ‘İçeri giren ne yapabilir, neye erişebilir?’ sorusu en az o kadar kritik. Kullanıcıları sisteme almak bir kapıdan geçirmek gibi ama içeride herkesin her odaya giremeyeceğini de tasarlamalısın. Kim hangi veriye erişebilir, hangi işlemi yapabilir. Bunları baştan tanımlamak IDOR’u doğmadan öldürür.

Her nesne erişiminde server-side kontrol yap. Sorguyu kullanıcının oturumuna bağla:

# Zafiyetli
Project.find(params[:id])

# Güvenli
current_user.projects.find(params[:id])

İkinci versiyonda saldırgan ID’yi değiştirse bile, sorgu yalnızca o kullanıcının projelerinde arama yapıyor. Kendi scope’u dışında bir sonuç dönmüyor.

UUID kullan, ama buna güvenme. Sıralı ID’ler (1, 2, 3…) yerine UUID kullanmak brute-force saldırılarını zorlaştırır. Ama nesne düzeyinde yetkilendirme kontrolü yoksa UUID de seni kurtarmaz. Sadece keşfedilmeyi geciktirir.

Varsayılan olarak reddet (deny by default). Her endpoint başlangıçta kapalı olmalı. Sadece açıkça izin verilmiş işlemler geçmeli.

Sonuç

• IDOR, kimlik doğrulamanın değil yetkilendirmenin eksikliğinden doğar.
• Otomatik tarayıcılar çoğu zaman yakalayamaz; en iyi test yöntemi iki hesap ve dikkatli bir göz.
• URL’deki ID’yi UUID yapmak problemi çözmez, sadece erteler. Asıl çözüm sunucu tarafında nesne düzeyinde kontrol.
• Gerçek dünya örnekleri gösteriyor ki bu zafiyet Uber’den Facebook’a kadar her ölçekteki sistemde görülüyor.
• Test için karmaşık bir araç seti gerekmiyor. Burp Suite ve temel HTTP bilgisi yeterli.

Kaynakça

1. OWASP Top 10:2021 — A01 Broken Access Control
2. PortSwigger — Insecure Direct Object References
3. OWASP — IDOR Prevention Cheat Sheet
4. HackerOne #254151 — Uber: activateFuelCard IDOR
5. HackerOne #1116387 — Uber Eats: GraphQL IDOR
6. Youssef Sammouda — Facebook Bug Bounty Writeupları
7. Black Hills InfoSec — Autorize ile Erişim Kontrolü Testi
8. IDOR: Web Uygulamalarının Gizli Tehdidi (Türkçe)
9. HackerOne #3027478 - TikTok LIVE IDOR (2024)