IDOR Zaafiyetini Anlamak: Gerçek Vaka Örnekleri

IDOR Zafiyeti:​

Güvensiz Doğrudan Nesne Referansı (Insecure Direct Object Reference - IDOR), bir web uygulamasının, kullanıcı tarafından sağlanan girdiyi (örneğin bir URL'deki kimlik numarası) arka uçtaki nesnelere (veritabanı kayıtları, dosyalar vb.) erişmek için yeterli yetkilendirme kontrolü yapmadan doğrudan kullandığında ortaya çıkan kritik bir erişim kontrolü zafiyetidir. OWASP Top 10 listesinde "Bozuk Erişim Kontrolü" (Broken Access Control) kategorisinin bir parçası olan IDOR, özellikle modern API tabanlı sistemlerde "Bozuk Nesne Düzeyinde Yetkilendirme" (Broken Object Level Authorization - BOLA) olarak adlandırılır ve en yaygın ve yıkıcı güvenlik açıklarından biridir.
Bu zafiyet, saldırganların basitçe tanımlayıcıları değiştirerek başka kullanıcılara ait hassas bilgilere yetkisiz erişmesine, verileri değiştirmesine veya silmesine olanak tanır. Geleneksel güvenlik araçları (WAF, DAST, SAST), istekler meşru göründüğü ve bir iş mantığı hatası olduğu için IDOR'u tespit etmekte genellikle zorlanır. Bu nedenle, tespiti büyük ölçüde manuel güvenlik testleri ve yaratıcılık gerektirir.
Önlemenin temel taşı, her bir isteğin sunucu tarafında sıkı bir şekilde doğrulanmasıdır. Bu, kimliği doğrulanmış kullanıcının, talep ettiği belirli nesne üzerinde işlem yapma yetkisine sahip olup olmadığını her seferinde kontrol eden nesne düzeyinde yetkilendirme mekanizmalarının uygulanmasını içerir. Doğrudan referanslardan kaçınmak, tahmin edilemez tanımlayıcılar (UUID gibi) kullanmak ve erişim kontrol mantığını merkezileştirmek, IDOR riskini azaltmak için en iyi uygulamalardır.

IDOR Nedir?​

IDOR, bir web uygulamasının, veritabanı anahtarı, dosya adı veya kullanıcı kimliği gibi dahili bir uygulama nesnesine yönelik doğrudan bir referansı, bu referansları manipüle edebilecek olan kullanıcılara ifşa etmesiyle ortaya çıkan bir güvenlik açığıdır. Zafiyetin özü, uygulamanın, bir nesneye erişim talebinde bulunan kullanıcının bu eylem için gerçekten yetkili olup olmadığını sunucu tarafında doğrulamayı ihmal etmesidir. Bu durum, temelinde bir iş mantığı ve yetkilendirme problemidir.
IDOR, OWASP tarafından popüler hale getirilmiş bir terim olup, geniş "Bozuk Erişim Kontrolü" kategorisi altında yer alan spesifik bir hatadır. Saldırganların sadece bir parametreyi değiştirerek yetki sınırlarını aşmasına olanak tanıdığı için hem yaygın hem de tehlikelidir.

Nasıl Çalışır?​

IDOR zafiyetleri, bir uygulama kullanıcıdan gelen girdiyi nesnelere erişmek için doğrudan kullandığında ve uygun yetkilendirme kontrolleri yapmadığında ortaya çıkar.
Örnek Senaryo: Bir e-ticaret sitesi, kullanıcıların sipariş detaylarını şu URL yapısıyla gösterir: https://ornek-site.com/siparislerim?siparis_id=12345
Eğer uygulama, oturum açmış kullanıcının gerçekten 12345 numaralı siparişin sahibi olup olmadığını kontrol etmezse, bir saldırgan siparis_id parametresini 12346 olarak değiştirerek başka bir kullanıcının sipariş bilgilerine erişebilir.
Bu manipülasyon sadece URL parametreleriyle sınırlı değildir; HTTP istek gövdeleri, başlıklar (headers), çerezler (cookies) ve API çağrılarındaki JSON nesneleri gibi kullanıcı tarafından kontrol edilebilen her yerde gerçekleşebilir.

API Güvenliğindeki Yeri: BOLA​

Modern API odaklı mimarilerde IDOR zafiyeti, OWASP API Security Top 10 listesinde birinci sırada yer alan "Bozuk Nesne Düzeyinde Yetkilendirme" (Broken Object Level Authorization - BOLA) olarak adlandırılır. API'ler, doğaları gereği nesne tanımlayıcılarını (örneğin, /api/users/{userID}) sıkça kullandığından, bu zafiyete karşı özellikle savunmasızdırlar. BOLA, bir API uç noktasının, istemciden gelen bir nesne kimliğini işlerken, istemcinin o nesne üzerinde işlem yapma yetkisi olup olmadığını doğrulamaması durumunda meydana gelir.

Teknik Tezahürler​

IDOR zafiyetleri, uygulamaların farklı noktalarında çeşitli şekillerde ortaya çıkabilir:

• URL ve Parametre Manipülasyonu: En yaygın türdür. Saldırgan, URL'deki id, user, account, file gibi parametrelerin değerlerini değiştirir.
• Gövde (Body) Manipülasyonu: POST veya PUT gibi isteklerin gövdesinde gönderilen JSON veya form verilerindeki kimlik değerlerinin (örneğin {"user_id": 123}) değiştirilmesiyle gerçekleştirilir.
• Çerez (Cookie) ve JSON ID Manipülasyonu: Kullanıcı veya oturum kimliklerinin çerezlerde veya JWT (JSON Web Token) gibi belirteçlerde saklandığı durumlarda, bu değerlerin çözülüp (decode) değiştirilmesi ve sunucuya geri gönderilmesiyle istismar edilebilir.
• Dizin/Yol Gezginliği (Path Traversal): Uygulama, dosya sistemindeki statik dosyalara (örneğin, indir.php?dosya=12144.txt) doğrudan referans verdiğinde, saldırgan dosya adını veya yolunu değiştirerek yetkisiz dosyalara erişebilir. Bu durum bazen ../ gibi karakterler kullanılarak sistem dosyalarına erişime kadar varabilir.

Blind (Kör) IDOR​

Blind IDOR, yapılan isteğin yanıtında doğrudan bir veri sızıntısı olmamasına rağmen, arka planda yetkisiz bir işlemin başarıyla gerçekleştirildiği durumlardır. Örneğin, bir saldırgan başka bir kullanıcının user_id'sini kullanarak profil güncelleme isteği gönderdiğinde, yanıt "Profil güncellendi" gibi genel bir mesaj olabilir, ancak arka planda diğer kullanıcının bilgileri gerçekten değişmiş olur. Bu tür zafiyetlerin tespiti daha zordur.

Potansiyel Etkiler​

IDOR zafiyetinin sonuçları, erişilen verinin hassasiyetine bağlı olarak yıkıcı olabilir:

• Hassas Bilgi Sızıntısı: Kişisel kimlik bilgileri, finansal veriler, sağlık kayıtları gibi hassas bilgilerin ifşa edilmesi.
• Veri Manipülasyonu ve Silinmesi: Saldırganların başka kullanıcılara ait verileri değiştirmesi veya silmesi, sistem bütünlüğünü bozar.
• Hesap Ele Geçirme: Şifre sıfırlama veya e-posta değiştirme gibi işlevlerde IDOR bulunması, hesapların tamamen ele geçirilmesine yol açabilir.
• Finansal Dolandırıcılık: Sipariş detaylarını, ödeme bilgilerini veya transfer işlemlerini manipüle ederek finansal kayıplara neden olma.
• Marka ve İtibar Hasarı: Büyük bir veri sızıntısı, kurumun itibarına ve müşteri güvenine ciddi zarar verir.
• Hukuki ve Cezai Yaptırımlar: Veri koruma yasalarının (KVKK, GDPR gibi) ihlali nedeniyle yüksek para cezaları ve yasal sorumluluklar doğurur.

IDOR Zafiyetlerinin Tespiti​

IDOR, bir iş mantığı hatası olduğu için geleneksel otomatik güvenlik tarayıcıları tarafından tespit edilmesi zordur.

Neden Tespit Edilmesi Zordur?​

• WAF ve Güvenlik Duvarları: IDOR saldırılarında kullanılan HTTP istekleri genellikle sözdizimsel olarak tamamen geçerlidir ve kötü amaçlı bir kod içermez. Bu nedenle, WAF'lar bu trafiği meşru kullanıcı trafiğinden ayırt edemez.
• DAST Araçları: Dinamik tarayıcılar, bir uygulamanın "sahiplik" veya "yetki" bağlamını anlayamaz. Bir isteğe 200 OK yanıtı aldığında, verinin yanlış kullanıcıya gösterildiğini fark edemez.
• SAST Araçları: Statik kod analiz araçları, yetkilendirme kontrollerinin kodun farklı katmanlarında (örneğin, middleware) veya merkezi bir yapıda uygulanması durumunda yanıltıcı olabilir ve çok sayıda yanlış pozitif (false positive) üretebilir.

Gerçek Dünya Vaka Çalışmaları ve Hukuki Boyut​

Önemli Veri İhlalleri​

• First American Financial Corp. (2019): Yaklaşık 885 milyon hassas belge (sosyal güvenlik numaraları, banka hesap bilgileri, vergi kayıtları) basit bir IDOR zafiyeti nedeniyle ifşa oldu. Belgeler, kimlik doğrulaması gerektirmeyen ve sıralı numaralara sahip URL'ler üzerinden erişilebiliyordu. Bu vaka, en basit IDOR hatalarının bile ne kadar büyük bir felakete yol açabileceğinin simgesidir.
• Peloton (2021): Bir API uç noktasındaki BOLA/IDOR zafiyeti, kullanıcıların profillerini "gizli" olarak ayarlamalarına rağmen özel verilerinin (yaş, konum, egzersiz istatistikleri) yetkisiz kişiler tarafından erişilmesine olanak tanıdı.
• Uber & Facebook: Her iki şirket de geçmişte, saldırganların API isteklerindeki kullanıcı kimliklerini değiştirerek başka kullanıcılar adına işlem yapmasına (örneğin, fotoğraf silme) veya verilerine erişmesine olanak tanıyan IDOR zafiyetleri yaşamıştır.

Sonuç​

Güvensiz Doğrudan Nesne Referansı (IDOR), basitliğine rağmen en yıkıcı web güvenlik açıklarından biri olmaya devam etmektedir. İstismarının kolay olması ve otomatik araçlarla tespitinin zorluğu, onu saldırganlar için cazip bir hedef haline getirmektedir. Kuruluşlar için IDOR ile mücadele, yalnızca kod yamamaktan öte, güvenliği yazılım geliştirme sürecinin en başından itibaren entegre eden bütünsel bir yaklaşım gerektirir. "Varsayılan Olarak Reddet" (Deny by Default) ilkesini benimsemek ve her istekte nesne sahipliğini sunucu tarafında titizlikle doğrulamak, bu yaygın ve tehlikeli zafiyete karşı en sağlam savunma hattını oluşturur.