Güvensiz Doğrudan Nesne Referansı (IDOR)

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Bozuk Erişim Denetimi
Tipik Önem Derecesi Yüksek
OWASP A01:2021 – Bozuk Erişim Denetimi
CWE CWE-639 – Kullanıcı Denetimindeki Anahtar Üzerinden Yetkilendirme Atlatma
Diğer adları IDOR, Nesne Düzeyinde Yetkilendirme Hatası, Broken Object Level Authorization (BOLA)
Etkilenen sistemler Web uygulamaları, REST API'ler, mobil arka uçlar — sunucu tarafındaki nesnelere atıfta bulunmak için tahmin edilebilir tanımlayıcılar kullanan her sistem

Genel Bakış

Güvensiz Doğrudan Nesne Referansı (IDOR), bir uygulamanın istemci tarafından sağlanan bir tanımlayıcıyı — tam sayı ID, UUID, dosya adı veya benzeri bir değer — sunucu tarafındaki bir nesneyi bulmak için kullanırken, istekte bulunan kullanıcının o nesneye erişim yetkisini doğrulamaması durumunda ortaya çıkar. Denetim eksik ya da yetersiz olduğu için saldırgan, başka bir kullanıcıya veya varlığa ait verilere ulaşmak ya da bunları değiştirmek amacıyla farklı bir tanımlayıcı kullanabilir.

IDOR bir enjeksiyon güvenlik açığı değildir; tamamen bir erişim denetimi hatasıdır. En yaygın web uygulaması güvenlik riski kategorisi olan OWASP A01:2021 – Bozuk Erişim Denetimi kapsamında yer alır ve resmi olarak CWE-639 şeklinde sınıflandırılır. API güvenliği bağlamında aynı örüntü genellikle Broken Object Level Authorization (BOLA) olarak adlandırılır ve OWASP API Security Top 10'da API1:2023 olarak vurgulanır.

Nasıl çalışır?

Güvenlik açığı, üç adımlı bir örüntünün üçüncü adımında bozulmasıyla ortaya çıkar: (1) uygulama, nesneleri tanımlayıcılarla depolar; (2) bu tanımlayıcıları URL'ler, istek gövdeleri veya çerezler aracılığıyla istemcilere açar; (3) başvurulan nesneyi sunmadan veya değiştirmeden önce sahipliği ya da izni doğrulamaz.

  • Öngörülebilir ardışık ID'ler: GET /invoices/10042 gibi bir URL, /invoices/10041 ve /invoices/10043 adreslerinde de fatura bulunduğunu ortaya koyar. Saldırgan bu değerler üzerinde yineleme yapar (IDOR numaralandırma veya yatay ayrıcalık yükseltme olarak bilinir).
  • Belirsiz ancak açık tanımlayıcılar: UUID veya karma ID'ler bile yetkilendirme denetiminin yerini tutamaz. Sunucu arayanın haklarını doğrulamadığı sürece tanımlayıcının belirsizliği yalnızca zayıf bir güvenlik-by-obscurity koruması sağlar.
  • Dikey ayrıcalık yükseltme: IDOR, daha yüksek ayrıcalık düzeyindeki nesnelere erişmek için de istismar edilebilir; örneğin bir yönetim uç noktasında normal kullanıcı hesap ID'si yerine yönetici hesap ID'si kullanılması.
  • POST/PUT/DELETE hedefleri: Yazma işlemleri de aynı ölçüde etkilenir. Saldırgan, istek gövdesine veya yoluna başka bir kullanıcının kaydına ait tanımlayıcıyı ekleyerek o kaydı değiştirebilir veya silebilir.
  • Parametrelerdeki dolaylı referanslar: Dosya indirme uç noktaları (/download?file=report_user123.pdf), dışa aktarma işlevleri ve form alanlarına gömülü referans ID'leri yaygın IDOR saldırı yüzeylerini oluşturur.

Basit bir kavram kanıtı şu şekilde görünür:

GET /api/orders/5512 HTTP/1.1
Authorization: Bearer <kurban_token_gerekmez>

# Saldırgan 5512 yerine 5513 kullanır:
GET /api/orders/5513 HTTP/1.1
Authorization: Bearer <saldirgan_token>

HTTP/1.1 200 OK
{ "order_id": 5513, "customer": "kurban@ornek.com", ... }

Sunucu, kimliği doğrulanmış kullanıcının 5513 numaralı siparişin sahibi olup olmadığını kontrol etmeden siparişi ID'ye göre aradığından kurban verilerini döndürür.

İş etkisi

Başarılı bir IDOR saldırısının sonuçları, açığa çıkan nesnelerin hassasiyetine ve mevcut yazma izinlerine bağlıdır:

  • Veri ihlali: Diğer kullanıcılara ait Kişisel Tanımlanabilir Bilgiler (KTB), finansal kayıtlar, sağlık verileri veya tescilli içerikler, otomatik numaralandırma yoluyla toplu olarak elde edilebilir.
  • Yasal ve uyumluluk riski: Kişisel verilere yetkisiz erişim, GDPR (Madde 33), HIPAA, PCI-DSS ve benzeri düzenlemeler kapsamında raporlanması gereken bir ihlal oluşturur; bu durum önemli cezalar ve zorunlu bildirimlere yol açabilir.
  • Hesap ele geçirme: Profil veya kimlik doğrulama nesnelerine IDOR yoluyla erişilebiliyorsa saldırganlar e-posta adresleri, parolalar veya bağlı ödeme yöntemleri değiştirebilir.
  • Veri manipülasyonu veya imhası: Yazma yetkisi bulunan IDOR, saldırganın kayıtları değiştirmesine ya da silmesine, iş açısından kritik verileri bozmasına veya diğer kullanıcılar için hizmet kesintisine yol açmasına olanak tanır.
  • İtibar kaybı: Müşteri verilerini açığa çıkaran bir IDOR açığının kamuoyuna duyurulması genellikle ciddi müşteri güveni kayıplarına neden olur.

IDOR güvenlik açıkları, kamuya açık hata ödül programlarında en sık ödüllendirilen bulgular arasında yer almakta ve ilgili verilere bağlı olarak çoğunlukla Yüksek veya Kritik olarak derecelendirilmektedir; bu durum gerçek dünya istismar edilebilirliklerini yansıtmaktadır.

Nasıl düzeltilir?

  1. Her nesne erişiminde sunucu tarafında yetkilendirme uygulayın: İsteğin kimliğini doğruladıktan sonra, kimliği doğrulanmış kimliğin (kullanıcı, hizmet hesabı veya rol) istekte belirtilen nesneyi okuma ya da değiştirme için açık izne sahip olup olmadığını doğrulayın. Bu denetim sunucuda gerçekleşmelidir — istemci tarafı filtreleme yetersizdir.
  2. Dolaylı referans haritaları kullanın: Ham veritabanı anahtarlarını açığa çıkarmak yerine, belirsiz bir token ile gerçek nesne ID'si arasında oturum veya kullanıcı başına bir eşleme tutun. Yalnızca sunucu eşlemeyi çözümler; bu sayede saldırganlar başka bir kullanıcının geçerli tokenını tahmin edemez.
  3. Nitelik tabanlı veya rol tabanlı erişim denetimi (ABAC/RBAC) uygulayın: Sahiplik ve izinleri açıkça modelleyin. Örneğin bir ORM sorgusu her zaman sonuçları kimliği doğrulanmış kullanıcıyla kapsamlamalıdır: SELECT * FROM orders WHERE id = ? AND user_id = ? — yalnızca SELECT * FROM orders WHERE id = ? değil.
  4. Mümkün olduğunda öngörülemeyen tanımlayıcılar kullanın: Ardışık tam sayılar yerine rastgele oluşturulmuş UUID'ler (v4) kullanmak numaralandırmayı zorlaştırır; ancak bu, derinlemesine savunma önlemidir ve yetkilendirmenin yerini tutmaz.
  5. Erişim denetimini merkezi olarak uygulayın ve test edin: Uç nokta başına geçici denetimler yerine birleşik bir yetkilendirme ara yazılımı veya kütüphanesi kullanın. Uç noktalar arasındaki tutarsızlık, gözden kaçan IDOR güvenlik açıklarının başlıca nedenidir.
  6. Erişim anomalilerini kayıt altına alın ve uyarı gönderin: Tek bir hesabın nesne tanımlayıcılarına hızla ardışık erişimi, IDOR numaralandırmasının güçlü bir sinyalidir. Nesne erişim uç noktalarında hız sınırlaması ve anomali tespiti uygulayın.
  7. Güvenlik testlerine IDOR senaryolarını dahil edin: Otomatik tarayıcılar, manuel sızma testleri ve kod incelemeleri; bir kimlik doğrulamalı oturumun, farklı bir oturuma ait nesnelere erişip erişemediğini açıkça test etmelidir. Sensagraph, web uygulama uç noktalarında IDOR örüntülerini otomatik olarak tespit eder.

Kaynaklar

Sıkça sorulan sorular

Bozuk Erişim Denetimi (OWASP A01:2021), kimliği doğrulanmış kullanıcıların yapabileceklerini kısıtlamadaki tüm hataları kapsayan geniş bir kategoridir. IDOR ise bu kategori içindeki belirli bir örüntüdür: uygulamanın dahili bir nesne tanımlayıcısını açığa çıkarması ve başvurulan nesneyi sunmadan veya değiştirmeden önce istekte bulunan kullanıcının yetkilendirmesini doğrulamamasıdır.

Evet. Bir tanımlayıcıyı gizlemek numaralandırmayı zorlaştırır, ancak bu bir yetkilendirme denetimi yerine geçmez. Sunucu UUID sağlandığında sahipliği doğrulamıyorsa, o UUID'yi başka yollarla (örneğin sızdırılmış bir URL, log kaydı veya paylaşılan bir bağlantı) edinen bir saldırgan kaynağa yetkisiz olarak erişebilir.

Hayır. IDOR, POST, PUT, PATCH ve DELETE dahil olmak üzere kullanıcı denetimindeki bir tanımlayıcıyla nesneye atıfta bulunan tüm HTTP yöntemlerini etkiler. Yazma yöntemi kullanan IDOR, başka bir kullanıcının verilerinin değiştirilmesine veya silinmesine olanak tanıdığından daha büyük hasar verebilir.

Broken Object Level Authorization (BOLA), OWASP API Security Top 10'da (API1:2023) IDOR ile aynı temel zayıflık için kullanılan terimdir. BOLA terimi API odaklı tartışmalarda tercih edilirken, IDOR web uygulama güvenliğindeki tarihsel yaygın terimdir.

İki ayrı kimlik doğrulamalı kullanıcı hesabı oluşturun ve A hesabıyla normal kullanım sırasında karşılaşılan tüm nesne tanımlayıcılarını kaydedin. Ardından B hesabının oturumunu kullanarak aynı tanımlayıcılara erişmeye veya bunları değiştirmeye çalışın. Herhangi bir başarılı hesaplar arası erişim, IDOR güvenlik açığına işaret eder. Otomatik araçlar ve özel tarayıcılar da yaygın IDOR örüntülerini geniş ölçekte tespit edebilir.