Hızlı cevap: IDOR (Insecure Direct Object Reference, güvensiz doğrudan nesne referansı), bir kullanıcının başkasına ait veriye, sadece adres çubuğundaki ya da istekteki bir kimlik numarasını değiştirerek erişebilmesidir. Örneğin fatura adresiniz siteproje.com/fatura/1043 ise ve 1044 yazdığınızda başka bir müşterinin faturası açılıyorsa, orada bir IDOR vardır. Bu, daha geniş bir sınıf olan Broken Access Control (bozuk erişim denetimi) kategorisine girer ve OWASP Top 10 2021 listesinin bir numarasıdır. Kök neden hep aynıdır: sunucu, isteği yapanın o kaynağa erişim hakkı olup olmadığını her istekte kontrol etmez. Çözüm, yetki kontrolünü istemciye değil, her zaman sunucu tarafında ve kaynağın sahibine göre yapmaktır.

Erişim denetimi açıkları, teknik olarak en basit ama etkisi en yüksek zafiyetlerden biridir. Bir SQL injection bulmak beceri ister; bir IDOR bulmak çoğu zaman sadece bir sayıyı bir artırmaktır. Buna rağmen ve belki tam da bu yüzden, çok yaygındır. Bu yazıda IDOR ve Broken Access Control'ün türlerini, nasıl bulunduğunu ve nasıl doğru savunulduğunu anlatıyoruz.

Broken Access Control türleri

Erişim denetimi iki soruya cevap vermelidir: "Bu kişi kim?" (kimlik doğrulama) ve "Bu kişi bunu yapabilir mi?" (yetkilendirme). Broken Access Control, ikinci sorunun yanlış cevaplanmasıdır.

  • Yatay yetki yükseltme (IDOR). Aynı seviyedeki başka bir kullanıcının verisine erişme. Kendi faturanız yerine başkasının faturasını görmek.
  • Dikey yetki yükseltme. Normal kullanıcının yönetici işlevlerine erişmesi. Örneğin sadece adres tahmin ederek yönetim paneline girmek.
  • Fonksiyon seviyesi eksik denetim. Arayüzde gizlenmiş ama sunucuda korunmamış işlemler. Buton görünmüyor diye güvenli sanmak.
  • İstemciye güvenmek. Yetkiyi sadece arayüzde gizleyip sunucuda kontrol etmemek.

IDOR nasıl bulunur

Mantık basittir: uygulamanın nesnelere nasıl referans verdiğine bakılır ve bu referans değiştirilir.

Referans türü Örnek Risk
Sıralı kimlik /siparis/1043 Yüksek, tahmin kolay
Kullanıcı adı /profil/ahmet Orta, sayılabilir
Tahmin edilemez kimlik (UUID) /dosya/9f2c... Düşük ama tek başına yetmez
Dosya yolu /indir?dosya=rapor.pdf Yol dolaşımına açık

Kritik yanılgı şudur: tahmin edilemez bir kimlik (UUID) kullanmak IDOR'u gizler ama çözmez. Kimlik sızarsa (bir logda, bir paylaşım linkinde, bir yönlendirmede) ve sunucu yine sahiplik kontrolü yapmıyorsa, açık yerinde durur. UUID bir güvenlik önlemi değil, bir zorlaştırıcıdır.

Neden bu kadar yaygın

  • Otomatik tarayıcılar zorlanır. IDOR, iş bağlamı gerektirir. Bir tarayıcı 1043 ile 1044'ün farklı kullanıcılara ait olduğunu bilemez. Bu yüzden otomatik zafiyet taraması çoğu IDOR'u kaçırır; insan gözü gerekir.
  • Geliştirici "kim erişir ki" varsayar. Linki bilmeyen erişemez sanılır. Oysa linkler paylaşılır, sızar, tahmin edilir.
  • Mikroservislerde dağınık yetki. Her servis kontrolü başkasına bıraktığını sanır, kimse yapmaz.

Doğru savunma

1. Her istekte sunucu tarafı yetki kontrolü

Altın kural: sunucu, her kaynak isteğinde "bu oturum bu kaynağa erişebilir mi" sorusunu sormalıdır. Sorgu, oturumdaki kullanıcı kimliğiyle sınırlanmalıdır. Yani "1044 numaralı faturayı getir" değil, "bu kullanıcının 1044 numaralı faturasını getir" sorgusu yazılır; kayıt başkasınınsa hiç dönmez.

2. Merkezi yetkilendirme

Yetki kontrolü her uçta ayrı ayrı yazılırsa biri unutulur. Merkezi bir katman ya da politika motoru, kararı tek yerden verir. Kimlik ve erişim yönetimi (IAM) yaklaşımı bunun temelidir.

3. Varsayılan reddet

Erişim açıkça izin verilmedikçe reddedilmelidir. Yeni bir uç eklendiğinde varsayılan güvenli olmalıdır.

4. Referansları dolaylı yapmak

Doğrudan veritabanı kimliği yerine, oturuma özel dolaylı referanslar kullanmak ek katman sağlar. Ama bu, sunucu tarafı sahiplik kontrolünün yerine geçmez; onunla birlikte kullanılır.

Gerçek etki

IDOR ve Broken Access Control, veri ihlallerinin en sık nedenlerindendir. Bir kullanıcı numarasını artırarak binlerce müşterinin verisine ulaşmak mümkün olabilir. Bu, KVKK veri ihlali bildirimi gerektiren bir olaya dönüşebilir. Bu yüzden erişim denetimi, web uygulaması sızma testinde en öncelikli kontrol başlıklarından biridir.

Sık sorulan sorular

IDOR ile Broken Access Control aynı şey mi? IDOR, Broken Access Control'ün bir alt türüdür. Broken Access Control daha geniş bir şemsiyedir; IDOR onun en bilinen örneğidir.

UUID kullanırsam IDOR biter mi? Hayır. UUID tahmini zorlaştırır ama sahiplik kontrolünün yerini tutmaz. Kimlik sızarsa açık devam eder. Sunucu her istekte yetki kontrolü yapmalıdır.

IDOR'u otomatik tarayıcı bulur mu? Genelde bulamaz, çünkü iş bağlamı gerekir. Elle test ve iki farklı hesapla karşılaştırma en etkili yöntemdir.

Butonu arayüzden kaldırmak yeterli mi? Hayır. Arayüzde gizlemek güvenlik değildir. Sunucu, işlevi isteyen herkesin yetkisini kontrol etmelidir.

Kaynaklar

Uygulamanızdaki IDOR ve erişim denetimi açıklarını iki hesaplı karşılaştırmalı testlerle ve çalışan kanıtla tespit ettirmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan sızma testi ve güvenli kod denetimi hizmeti veriyoruz.