- Konu sahibi
- #1
IDOR açığı nedir?
IDOR (Insecure Direct Object Reference), istemcinin değiştirebildiği bir nesne tanımlayıcısı üzerinden yetkisi dışındaki veriye veya işleve erişebilmesidir. Örneğin bir uygulama siparişleri
/orders/1001 gibi bir adresle gösteriyor ve kullanıcı 1001 yerine 1002 yazarak başka müşterinin siparişini görebiliyorsa bu bir IDOR açığıdır. Sorun, numaranın tahmin edilebilir olması değil, sunucunun nesnenin gerçekten isteği yapan kullanıcıya ait olduğunu denetlememesidir.Nasıl çalışır?
Uygulama istemciden bir nesne kimliği alır. Güvenli tasarımda sunucu bu kimliği yalnızca biçimsel olarak doğrulamaz; oturumdaki kullanıcının ilgili nesne üzerinde gereken yetkiye sahip olup olmadığını da kontrol eder. IDOR bulunan tasarımda ise sunucu çoğunlukla şu mantık hatasına düşer:
Kod:
nesne = VeritabanındanBul(istektenGelenId)
nesneyiGöster(nesne)Yalnızca sahibine özel bir nesne için aşağıdaki sözde kod, sorguyu yetkili kapsam içinde çalıştırmayı gösterir; gerçek bir programlama dilinde çalıştırılacak kod değildir:
Kod:
nesne = VeritabanındanBul(
id = istektenGelenId,
sahip = oturumdakiKullanici
)
Eğer nesne yoksa 404 veya uygun bir yetki yanıtı döndürKontrol; görüntüleme, güncelleme, silme, indirme, ödeme, davet ve yönetim işlemlerinin her birinde ayrı ayrı yapılmalıdır. Bir kullanıcının nesneyi görebilmesi, onu değiştirebileceği veya silebileceği anlamına gelmez.
Somut örnek
Varsayımsal bir e-ticaret uygulamasında Ali’nin sipariş kimliği
1001, Ayşe’nin sipariş kimliği 1002 olsun. Ali oturum açtıktan sonra kendi siparişini görüntülemek için şu isteği gönderir:
Kod:
GET /orders/1001Ali aynı oturumla kimliği
1002 olarak değiştirip Ayşe’nin sipariş ayrıntılarını alabiliyorsa okuma IDOR’u vardır. Şu istek de benzer biçimde risklidir:
Kod:
DELETE /api/invoices/1002Sunucu silme işleminden önce faturanın Ali’ye ait olduğunu kontrol etmiyorsa bu kez yalnızca veri ifşası değil, yetkisiz işlem açığı oluşur. Kimlikleri UUID gibi tahmin edilmesi zor değerlere çevirmek saldırıyı güçleştirebilir; ancak tek başına yetkilendirme kontrolünün yerini tutmaz.
Düzeltme yaklaşımını seçin
| Yaklaşım | Ne sağlar? | Sınırlaması |
|---|---|---|
| Sahiplik veya ilişki filtresi | Nesneyi yetkili kapsam içinde arar | Her nesne türü için doğru kural yazılmalıdır |
| Rol ve izin kontrolü | Yönetim ve özel işlemleri sınırlar | Tek başına nesne sahipliğini kanıtlamaz |
| Tahmin edilmesi zor kimlik | Kimliklerin sırayla denenmesini zorlaştırır | Yetkisiz erişimi engellemez |
| Merkezi yetkilendirme katmanı | Kontrollerin tutarlı uygulanmasına yardım eder | Yanlış yapılandırma tüm uç noktaları etkileyebilir |
Kendi uygulamanızda güvenli doğrulama
Testi yalnızca sahip olduğunuz veya açıkça izin verilen uygulamalarda, tercihen izole bir test hesabı ve test verisiyle yapın. İki farklı kullanıcı hesabı oluşturmak, sahiplik kontrolünü gerçekten doğrulamanın en anlaşılır yoludur.
- Kullanıcı A ile oturum açın ve A’ya ait bir nesnenin kimliğini belirleyin. Görüntüleme, düzenleme, silme ve indirme gibi ilgili uç noktaları not edin.
- Kullanıcı B ile aynı türden ayrı bir test nesnesi oluşturun ve kimliğini kaydedin.
- Kullanıcı A’nın oturum bilgilerini koruyarak yalnızca nesne kimliğini B’nin kimliğiyle değiştirin. Bunu hem adres yolu hem de istek gövdesi veya sorgu parametresi içinde kullanılan kimlikler için deneyin.
- Her işlemde beklenen sonucu kontrol edin. A’nın B’ye ait veriyi okuyamaması ve B’nin nesnesini değiştirememesi veya silememesi gerekir.
- Yetkisiz istek sunucu tarafında reddediliyorsa sunucu günlüklerinde reddedilme nedenini ve nesne sahibinin doğru hesaplandığını doğrulayın. Yetkisiz yanıt başarılı veri veya işlem sonucu döndürüyorsa açığı düzeltin ve aynı testi tekrarlayın.
Sonuç yalnızca arayüzde gizleme veya düğmeyi devre dışı bırakma ile değerlendirilmemelidir. Tarayıcı geliştirici araçlarıyla gönderilebilen bir istek, doğrudan istemci dışından da gönderilebilir; kararın sunucuda verilmesi gerekir.
Düzeltme seçenekleri ve karar ölçütü
Bu sahiplik örneğini her sisteme aynen uygulamayın. Paylaşılan veya kuruluşa ait nesnelerde sahiplikten başka üyelik, paylaşım ve işlem izinleri gerekebilir. Her nesne türü için erişim kuralını açıkça belirleyin. Bazı nesneler kullanıcıya, bazıları kuruluşa, role veya belirli bir ilişkiye bağlı olabilir. Liste uç noktalarında da aynı filtreyi uygulayın; yalnızca ayrıntı uç noktasını korumak yeterli değildir.
En sağlam temel, nesneyi kimliğe göre bulurken yetkili kapsamı sorguya dahil etmek ve hassas işlemler için ayrıca işlem izni kontrolü yapmaktır. Ayrıca hata yanıtlarının başka kullanıcıların nesnelerinin varlığını gereksiz yere açığa çıkarmamasına dikkat edin.
Sık yapılan hatalar
Yalnızca istemciyi kontrol etmek: Formdaki kimliği gizlemek, düğmeyi kaldırmak veya JavaScript ile engellemek koruma değildir. İstek sunucuya ulaştığında yetki yeniden hesaplanmalıdır.
Kimliği değiştirmeyi güvenlik sanmak: Sıralı sayı yerine UUID kullanmak tahmini zorlaştırır; fakat ele geçirilmiş veya paylaşılmış bir kimlik yine yetki kontrolü olmadan kullanılabilir.
Sadece GET isteklerini test etmek: IDOR; POST, PUT, PATCH, DELETE, dosya indirme ve rapor dışa aktarma işlemlerinde de bulunabilir. Her işlem için hem okuma hem değişiklik yetkisini test edin.
Yönetici rolünü normal kullanıcı gibi değerlendirmek: Yönetici hesapları geniş yetkiye sahip olabilir; test matrisi normal kullanıcı, aynı kuruluşun başka kullanıcısı ve farklı kuruluş kullanıcısını ayrı ele almalıdır.
