Broken access control nedir?

Broken access control, bir kullanıcının veya istemcinin yetkisi olmayan bir kaynağa ya da işleve erişebilmesidir. Uygulama giriş yapılmış olmayı yeterli sayıyor, kullanıcının o kaynağa gerçekten yetkili olup olmadığını sunucu tarafında denetlemiyorsa bu zafiyet oluşur. Sonuç; başka kullanıcıların verilerinin okunması, değiştirilmesi, silinmesi veya yönetici işlemlerinin yetkisiz yapılması olabilir.

Broken access control nasıl çalışır?​

Kimlik doğrulama, kullanıcının kim olduğunu belirler; yetkilendirme ise bu kullanıcının hangi işlemleri yapabileceğini belirler. Broken access control, genellikle ikinci kontrolün eksik, hatalı veya yalnızca tarayıcıya bırakılmış olması nedeniyle ortaya çıkar.

Varsayımsal bir uygulama, sipariş ayrıntısını şu istekle döndürüyor olsun:


Oturum açmış kullanıcı kendi siparişini görebiliyor. Kullanıcı URL'deki numarayı 1043 olarak değiştirdiğinde başka bir müşterinin siparişi de dönüyorsa uygulama yalnızca "oturum açılmış mı?" kontrolü yapıyor, "bu sipariş bu kullanıcıya mı ait?" kontrolünü yapmıyordur. Bu durum, nesne düzeyinde yetki denetimi eksikliğinin tipik örneğidir.

Aynı sorun yönetici sayfalarında, API uç noktalarında, dosya indirme adreslerinde, destek kayıtlarında ve silme veya dışa aktarma işlemlerinde de görülebilir.

Kontrol ederken izlenecek yol​

Bu incelemeyi yalnızca sahibi olduğunuz veya açıkça test izni verilen uygulamalarda yapın. Amaç, yetkisiz veriyi elde etmek değil, uygulamanın yetki kararını doğru verdiğini doğrulamaktır.

1. Uygulamadaki roller ile kaynak sahipliği kurallarını yazın. Örneğin normal kullanıcı yalnızca kendi siparişlerini, destek personeli yalnızca atanmış kayıtları, yönetici ise tüm kayıtları görebilir.
2. Her kritik işlem için beklenen sonucu belirleyin: görüntüleme, oluşturma, güncelleme, silme, indirme ve yönetim işlemlerini ayrı değerlendirin.
3. En az iki test hesabı ve gerekiyorsa farklı rollere sahip hesaplar oluşturun. Bir hesabın kaynağını diğer hesapla istemci tarafındaki adres veya istek verisini değiştirerek denetleyin.
4. Yetki kontrolünün sunucu tarafından yapıldığını doğrulayın. Butonu gizlemek, menüyü göstermemek veya JavaScript ile erişimi engellemek tek başına güvenlik kontrolü değildir.
5. Yetkisiz isteklerin reddedildiğini ve uygulamanın özel veri döndürmediğini kontrol edin. Başarısız sonuçtan sonra günlüklerde kullanıcı, kaynak, işlem ve karar bilgilerini inceleyin; parolaları veya oturum belirteçlerini günlüğe yazmayın.
6. Hatanın kaynağını düzelttikten sonra aynı işlemi tüm ilgili uç noktalarda yeniden test edin. Bir görüntüleme uç noktasını düzeltmek, güncelleme veya silme uç noktasının da düzeldiği anlamına gelmez.

Beklenen sonuç, kullanıcının kendi kaynağına izin verilen işlemle erişebilmesi; başka kullanıcıya ait veya rolünün dışında kalan kaynağın ise işlem yapılmadan reddedilmesidir. Yetki kararı istemciden gelen kullanıcı kimliği, rol adı veya kaynak sahibi bilgisine güvenerek verilmemelidir; bu bilgiler sunucuda doğrulanmış oturum ve veritabanındaki ilişki üzerinden belirlenmelidir.

Karar verirken önemli ayrımlar​

Aşağıdaki ayrım, bulunan sorunun kapsamını ve düzeltme yaklaşımını netleştirir.


Broken access control bulunduğunda yalnızca arayüzü değiştirmek, URL'leri tahmin edilmez yapmak veya kimlik numaralarını gizlemek yeterli çözüm değildir. Tahmin edilmesi zor bir kimlik, yetki kontrolünün yerine geçmez. Her hassas uç nokta, işlemin hedef kaynağı ve mevcut kullanıcı birlikte değerlendirilerek reddetme varsayılanıyla korunmalıdır.

Sık yapılan hatalar​

En yaygın hata, yalnızca sayfaları test edip doğrudan API isteklerini kontrol etmemektir. Bir başka hata, rol kontrolünü yalnızca menü görünürlüğüne bırakmaktır. Ayrıca okuma erişimi düzeltilirken güncelleme, silme, dosya indirme ve toplu işlem uç noktalarının unutulması da aynı açığın sürmesine neden olur. Yetki hatalarında güvenli varsayılan, gerekli izin açıkça kanıtlanamıyorsa işlemi yapmamaktır.

Sık sorulan sorular​

Yetkisiz bir kaynağa 403 yerine 404 dönmek uygun mudur?​

Politikanız kaynağın varlığını da gizlemeyi gerektiriyorsa 404 seçilebilir. Ancak durum kodunu değiştirmek yetki denetiminin yerine geçmez: sunucu özel veriyi döndürmemeli ve işlemi yapmamalıdır. Testlerde hem yanıt gövdesini hem veri değişikliğini kontrol edin.

Her kaynağı oturum açmayı zorunlu tutarak mı korumalıyım?​

Hayır. Herkese açık görsel veya yardım sayfası bilerek anonim erişime açık olabilir. Kaynağın kamuya açık olma kararı açıkça tanımlanmalı; özel dosya veya kullanıcı kaydı yanlışlıkla bu gruba düşmemelidir. Yetkilendirme, her kaynak için politikanın doğru uygulanmasıdır.