Broken Access Control Nedir? IDOR, BOLA ve Yetkilendirme Zafiyetleri

Yetkilendirme Nedir?

Bir web uygulamasında kullanıcı sisteme giriş yapması, her kaynağa erişebileceği anlamına gelmez. Kimlik doğrulama (Authentication) kullanıcının kim olduğunu doğrularken, yetkilendirme (Authorization) hangi işlemleri yapabileceğini belirler.

Doğru tasarlanmış bir yetkilendirme mekanizması, her kullanıcının yalnızca kendi rolüne uygun verilere ve fonksiyonlara erişmesini sağlar. Bu kontroller eksik veya hatalı uygulandığında saldırgan başka kullanıcılara ait verilere erişebilir, yetkisini yükseltebilir veya normalde erişemeyeceği yönetim fonksiyonlarını kullanabilir. Bu durum Broken Access Control olarak adlandırılır ve OWASP Top 10 listesinin en kritik risklerinden biridir.

Neden En Kritik Güvenlik Açığıdır?

Birçok kurum güvenlik yatırımlarını güvenlik duvarı, antivirüs veya WAF gibi teknolojilere odaklamaktadır. Ancak uygulamanın kendi yetkilendirme mantığında hata varsa, saldırgan sisteme giriş yaptıktan sonra bu güvenlik katmanlarını aşmasına gerek kalmadan kritik verilere ulaşabilir. Bu tür açıklar çoğu zaman otomatik güvenlik tarayıcıları tarafından tespit edilemez; çünkü sorun teknik bir zafiyetten çok, uygulamanın iş kurallarının yanlış uygulanmasından kaynaklanır.

Broken Access Control Türleri

1. Yatay Yetki Yükseltme (Horizontal Privilege Escalation)

Saldırgan, kendi yetki seviyesindeki başka bir kullanıcıya ait verilere erişebilir. Örneğin bir e-ticaret uygulamasında /orders/5481 bağlantısını açan kullanıcı, yalnızca sipariş numarasını /orders/5482 olarak değiştirerek başka müşteriye ait sipariş bilgilerine erişebiliyorsa kritik bir yetkilendirme açığı bulunmaktadır.

2. Dikey Yetki Yükseltme (Vertical Privilege Escalation)

Kullanıcı kendi rolünün üzerinde yetki kazanır. Normal bir kullanıcı /admin/users sayfasına erişebiliyorsa veya yalnızca yöneticilerin kullanması gereken API'leri çağırabiliyorsa, uygulamada ciddi bir yetkilendirme problemi bulunmaktadır.

3. IDOR (Insecure Direct Object Reference)

Günümüzde en sık karşılaşılan yetkilendirme açıklarından biridir. Uygulama bir kaynağa erişirken yalnızca nesne kimliğini (ID) kontrol edip, bu kaynağın gerçekten ilgili kullanıcıya ait olup olmadığını doğrulamıyorsa saldırgan farklı kayıtları görüntüleyebilir — örneğin invoice?id=1001 yerine invoice?id=1002 gönderildiğinde başka müşteriye ait fatura açılması.

4. BOLA (Broken Object Level Authorization)

Özellikle REST API uygulamalarında görülen modern IDOR çeşididir. GET /api/users/125/profile isteğini yapan kullanıcının gerçekten 125 numaralı kullanıcı olup olmadığı kontrol edilmiyorsa saldırgan farklı kullanıcı kayıtlarını okuyabilir. Mobil uygulamalar ve mikro servis mimarilerinde bu risk oldukça yaygındır.

Gerçek Bir Senaryo

Bir finans uygulamasında kullanıcılar kredi başvurularını çevrim içi olarak takip edebilmektedir. Yapılan sızma testi sırasında, başvuru numarasının URL üzerinde yer aldığı ve yalnızca bu numaranın değiştirilmesiyle farklı müşterilere ait başvuruların görüntülenebildiği tespit edilmiştir. Teknik olarak sistemde herhangi bir SQL Injection, XSS veya RCE açığı bulunmamasına rağmen, yalnızca eksik yetkilendirme kontrolü nedeniyle kimlik bilgileri, gelir belgeleri, kredi skorları ve başvuru sonuçları başka kullanıcılar tarafından görüntülenebilmektedir.

SecureSys Yetkilendirme Test Yaklaşımı

Yetkilendirme açıkları yalnızca otomatik araçlarla güvenilir şekilde tespit edilemez; bu nedenle manuel analizleri test sürecimizin merkezine yerleştiriyoruz. Testlerimiz rol bazlı erişim kontrollerini, kullanıcı değişimi senaryolarını, ID manipülasyonlarını, API nesne erişimlerini, çok kiracılı (multi-tenant) uygulamalarda tenant izolasyonunu ve sunucu tarafı doğrulama mekanizmalarını kapsar.

Yetkilendirme Açıkları Nasıl Önlenebilir?

• Her istekte sunucu tarafında yetki kontrolü yapılmalıdır.
• Kullanıcı kimlikleri istemciden gelen verilere güvenilerek belirlenmemelidir.
• Rol tabanlı (RBAC) veya öznitelik tabanlı (ABAC) erişim kontrolü uygulanmalıdır.
• API uç noktalarında nesne seviyesinde yetkilendirme doğrulanmalıdır.
• Tüm erişim denemeleri kayıt altına alınmalı ve düzenli izlenmelidir.

Risk ve İş Etkisi

Risk	İş Etkisi
Müşteri verilerinin görüntülenmesi	KVKK ve GDPR ihlali
Finansal kayıtların değiştirilmesi	Mali kayıp
Yetkisiz yönetici erişimi	Kritik sistemlerin kontrolünün kaybedilmesi
API üzerinden veri sızdırılması	Toplu veri ihlali

Broken Access Control, IDOR ve BOLA risklerine karşı uygulamanızın test edilmesi için Web Uygulama Sızma Testi Hizmeti sayfamızı, API'lerinize özel değerlendirme için API Güvenliği sayfamızı inceleyebilirsiniz.