IDOR ve bozuk erişim denetimi

Bir fatura sayfası açtın ve adres çubuğunda kendi fatura numaran duruyor. Numarayı bir azaltırsan ne olur? Uygulama oturumunu tanır, ama o kaydın sana ait olup olmadığını sormayabilir.

Doğrudan nesne referansı zafiyeti, kısaca IDOR, tam bu boşlukta doğar. Kimlik doğrulama sorusu ile yetkilendirme sorusu birbirine karışır. Bu derste iki sorunun farkını, açığın iki hesapla nasıl avlandığını, neden rastgele kimliğin tek başına çözüm olmadığını ve sahiplik denetimini sorgunun içine koymanın neden asıl savunma olduğunu göreceksin.

İki kavram sık karıştırılır ama ayrı sorular sorar. Kimlik doğrulama şunu sorar: sen kimsin? Sistem seni parolayla, jetonla ya da başka bir yöntemle tanır.

Yetkilendirme ise şunu sorar: bu kayda erişmeye hakkın var mı? İkinci soru atlandığında, oturum açan her kullanıcı başkasının verisini okuyabilir. IDOR tam bu ikinci sorunun eksikliğidir.

Uygulama seni doğru tanır, giriş yapmış olduğunu bilir, ama istediğin kaydın sahibi olup olmadığını denetlemez. Kimlik değeri adres çubuğunda, istek gövdesinde ya da bir parametrede göründüğü için, onu komşu bir değerle değiştirmek yeterlidir. Doğrulama var, yetki denetimi yoktur.

# Zafiyetli: yalnız kimlik sorulur
kayit = Fatura.query.get(fid)

# Sağlam: sahiplik sorguya girer
kayit = Fatura.query.filter_by(id=fid, musteri_id=current_user.id).first_or_404()

İki sürüm arasındaki fark tek bir koşulda görünür. Zafiyetli sürüm kaydı yalnız kimliğe göre çeker; oturum açan kullanıcının o kayda sahip olup olmadığını hiç sormaz. Sağlam sürümde ise sorgu iki koşulla çalışır: kimlik eşleşmeli ve kayıt isteği yapan müşteriye ait olmalı.

Sahiplik denetimi ayrı bir if satırı değil, sorgunun kendi filtresidir; bu yüzden kod incelemesinde de kolayca gözden kaçmaz, tersine hemen görülür. Aşağıdaki uçta bu ikinci koşulun sorguya hiç girmediğini göreceksin.

Erişim ihlali iki yönde işler. Yatay ihlalde aynı yetki düzeyindeki başka bir kullanıcının verisine ulaşırsın; senin gibi sıradan bir hesabın faturasını okumak buna örnektir. Dikey ihlalde ise kendi düzeyinin üstüne çıkarsın; sıradan kullanıcıyken yönetici ucunu çağırmak dikey yükseltmedir.

IDOR çoğu zaman yatay ihlalle anılır, ama aynı denetim eksikliği dikey yönde de görülür. Arayüzde yönetici menüsü gizlenmiş olabilir; istek yine de kabul edilirse, gizleme bir güvenlik önlemi değildir. Testte iki yönü de denersin: komşu kaydı ve bir üst yetkinin ucunu.

Komşu kimliğin açılması, denetim eksikliğinin yatay yüzüdür. Ama aynı eksiklik yukarı doğru da işler: sıradan bir hesabın yönetici ucunu çağırması dikey ihlaldir. İki yön de tek bir kök nedeni paylaşır, sunucunun yetki denetimini atlamasını.

Dikey yönde sık yapılan bir hata, yönetici işlevini yalnız arayüzde gizlemektir. Menü görünmese de uç adresi çoğu zaman tahmin edilir ya da eski bir sürümden bilinir; istek elle kurulup gönderilir. Sunucu denetim yapmıyorsa, gizli menü hiçbir koruma sağlamaz. Aşağıdaki senaryoları bu iki yöne, yatay ve dikey, göre ayır.

IDOR aramanın en verimli yolu iki hesapla çalışmaktır. Birinci hesapla bir kayıt oluşturur, kimliğini not edersin. Sonra ikinci hesabın oturumuyla aynı kaydı istersin. Yanıt 200 koduyla ve kaydın içeriğiyle dönüyorsa, denetim yok demektir.

403 dönüyorsa uç erişimi engelliyordur. 404 dönüyorsa kaydın varlığını gizliyor olabilir; kendi kaydınla komşu kaydın yanıtlarını karşılaştırmadan sonuca varmazsın. Bu yöntem otomatik araçla zor bulunur, çünkü tarayıcı dönen yanıtın kime ait olması gerektiğini bilmez. IDOR avı bu yüzden elle yapılır ve uygulamanın iş mantığını öğrenmeyi gerektirir.

IDOR, ödül avcılığında en sık bildirilen sınıflardandır. Sebebi basittir: bulmak derin teknik bilgi değil, dikkat ister. Uygulamanın kendi kurallarını öğrenen kişi kısa sürede sonuç alır.

Bir kayıt oluşturur, kimliğin nasıl üretildiğine bakar, sonra o kimliği başka bir hesapla dener. Bu sadelik açığı hem yaygın hem de tehlikeli yapar; çünkü aynı sadelikle gözden de kaçar. Geliştirici çoğu zaman kimlik doğrulamayı kurar, yetki denetimini eklemeyi unutur. Testte bu boşluğu aramak, en yüksek getirili işlerden biridir.

Kimliği yalnız adres çubuğunda arama. Aynı değer yol parçasında, sorgu parametresinde, istek gövdesinde, çerezde ya da gizli bir form alanında taşınabilir. Uygulama bazen kimliği gizli alanda tutar ve orada denetim yoktur.

Toplu uçlar ayrı bir risk taşır: dışa aktarma, arama ve rapor uçları çoğu zaman tek tek kayıtlardan daha gevşek yazılır. Tek bir istekle binlerce kaydın döndüğü bir uç, aynı hatanın en ağır biçimidir. Bu yüzden testte hem tekil kayıtları hem de toplu uçları, kimliğin geçebileceği her yeri denersin.

Eksik satırı görmek bir beceri; açığı düzenli biçimde aramak başka bir beceri. IDOR avında sıralı bir yöntem, hem yanlış pozitiften hem de gereksiz veri toplamaktan korur. Önce bilinen bir kimlik üretir, sonra farklı bir oturumla o kimliği çağırırsın. Sıra önemlidir, çünkü yanıtı tek başına okumak yanıltır.

Bir uç 404 döndürüyorsa, bu kaydın olmadığı anlamına gelmez; denetimli bir uç, var olan ama sana ait olmayan kaydı da gizlemek için 404 verebilir. Doğru yorum, komşu kaydın yanıtını kendi meşru kaydının yanıtıyla karşılaştırmaktan çıkar. Aşağıdaki adımları, iki hesapla sınamanın doğru sırasına koy.

Kimliği tahmin edilemez yapmak çözüm gibi görünür. Ardışık sayı yerine rastgele bir değer koyunca kaba kuvvet zorlaşır. Ama denetim yine yoktur.

Rastgele kimlik yalnız tahmini zorlaştırır, yetki sorusunu yanıtlamaz. Kimlik bir paylaşım bağlantısında, bir kayıt satırında ya da bir e-postada sızarsa kapı yeniden açılır; sızan kimliği alan herkes kaydı okur. Aynı biçimde, arayüzde bir düğmeyi gizlemek de güvenlik değildir.

Düğme kaybolsa bile istek elle kurulabilir. Gerçek denetim, isteğin ulaştığı sunucu katmanında, her istekte yeniden yapılır. Görünüşe dayanan hiçbir önlem, sunucu tarafı kontrolün yerini tutmaz.

Yanıt farklarını okumak da bir beceridir. Denetim yapan bir uç, yetkisiz isteğe tutarlı bir ret döndürür. Denetim yapmayan uç ise kaydı olduğu gibi verir.

Tespit tarafında bu fark bir sinyaldir: aynı kullanıcının kısa sürede çok sayıda farklı kimlik denemesi, kimlik değerlerinin ardışık taranması ve normalden fazla kayda erişim, bir IDOR taramasının izleridir. Uygulama günlüklerinde kullanıcı ve eriştiği kayıt sahibi birlikte tutulursa, bu desen alarma bağlanabilir. Savunma yalnız kodda değil, izlemede de kurulur.

Gerçek olaylarda IDOR'un etkisi büyüktür. Tek bir denetimsiz uç, binlerce kaydın sızmasına yol açabilir; kişisel veri söz konusu olduğunda bu, yasal bir bildirim yükümlülüğü doğurur. Bulguyu raporlarken kaç kayda erişilebildiğini bir tahminle belirtirsin.

Sayıyı doğrulamak için tüm kayıtları çekmen gerekmez; kimlik aralığından çıkan makul bir tahmin etkiyi anlatmaya yeter. Böylece hem bulgunun ciddiyeti gösterilir hem de gereksiz veri çoğaltması yapılmaz. Ölçülü kanıt, hem etik hem de yasal açıdan doğru olandır.

Kimlik değerinin biçimi de ipucu verir. Ardışık sayılar komşu kayıtları tahmin etmeyi kolaylaştırır; uzun rastgele değerler tahmini zorlaştırır ama tek başına yetki vermez. Bir uçta kimliğin nasıl üretildiğine bakmak, hangi yöntemin işe yarayacağını gösterir.

Ardışıksa dar bir aralık denenir; rastgeleyse kimliğin sızabileceği yerler, yani paylaşım bağlantıları ve günlükler öncelikli incelenir. Biçim ne olursa olsun asıl eksik hep aynıdır: sunucunun sahiplik denetimi yapmaması.

Bozuk erişim denetimi, OWASP listesinin en üst sırasında durur ve test edilen uygulamaların neredeyse tamamında bir biçimde görülür. Bunun bir nedeni, açığın otomatik araçla zor bulunmasıdır.

Tarayıcı, dönen bir yanıtın kime ait olması gerektiğini bilmez; kuralı ancak uygulamanın iş mantığını bilen bir insan koyar. Bu yüzden erişim denetimi testi elle, iki hesapla ve rol rol yürütülür. Aynı sebep savunmayı da belirler: kontrol, geliştiricinin her uçta tek tek hatırlamasına değil, merkezî ve varsayılan bir katmana dayanmalıdır.

Aynı hata yazma işlemlerinde daha ağır sonuç verir. Bir güncelleme isteğiyle başka kullanıcının profilini değiştirmek, rolünü yükseltmek ya da siparişini iptal etmek mümkün olabilir. Bu yüzden testte yalnız okuma uçlarına bakmazsın; güncelleme ve silme uçlarını da sahiplik açısından denersin. Rol tabanlı hatalar da aynı aileye girer.

Normal kullanıcı yönetici ucunu doğrudan çağırdığında ne oluyor? Arayüzde menü gizlenmiş olabilir, ama istek kabul ediliyorsa dikey yükseltme vardır. Yazma tarafındaki bir IDOR, veriyi yalnız okumakla kalmaz, kalıcı olarak değiştirir.

Savunmada asıl kural, sahiplik denetimini sorgunun içine koymaktır. Kaydı yalnız kimliğe göre değil, kimlik ve sahip birlikte eşleşince çekersin. Böylece komşu bir kimlik istense de sorgu boş döner. Her uçta elle yazılan kontrol er geç bir yerde unutulur; bu yüzden merkezi bir yetki ara katmanı işi kolaylaştırır.

Ortak katman denetimi varsayılan yapar ve istisnayı görünür kılar. Bu bulgu sınıfı otomatik testlere de taşınır: her uç için farklı rollerle yazılan testler, ileride eklenen bir uçta denetimin unutulmasını yakalar. Kişisel veri gördüğünde tek kayıt kanıtı alır, maskeler ve durursun; listenin tamamını çekmek kapsamı aşar.

Sunucu tarafı denetimin ne olduğunu ayırdın; bir de yetkili testte ölçüyü hatırla. Bir IDOR bulgusunu ispatlamak için binlerce kaydı indirmek gerekmez. Tek bir örnek açığı göstermeye yeter ve kişisel veriyi gereksiz yere çoğaltmaz. Bu ölçü yalnız nezaket değil, hem etik hem yasal bir sınırdır.

Kişisel veriyi gereğinden fazla toplamak, testin kapsamını aşar ve sızma riskini artırır. Etkiyi anlatmak için erişilebilen kayıt sayısını kimlik aralığından tahmin eder, dönen tek örneği maskeleyerek rapora eklersin. Son önermede bu ölçü kuralını sına.