Yetkilendirme Testi
Kırık erişim kontrolü, OWASP Top 10'un en tepesindeki risk kategorisidir ve gerçek ihlallerin en yaygın nedenlerindendir. Yetkilendirme testi, uygulamanızın “kim neye erişebilir” kuralını rol rol ve kaynak kaynak doğrular: yatay/dikey yetki yükseltme, IDOR/BOLA, işlev düzeyi kırık yetki ve çok kiracılı mimarilerde kiracı izolasyonu. Amacımız, her erişim kararının sunucu tarafında gerçekten zorlandığını kanıtlamaktır. Testler yalnızca yazılı yetkilendirme ve tanımlı kapsamla yürütülür.
Bu hizmet hangi sorunu çözer?
Yetkilendirme, uygulamalarda en çok gözden kaçan ve en pahalıya patlayan alandır çünkü kolayca “görünmez” biçimde kırılır. Arayüz doğru düğmeleri gizleyebilir; ancak asıl soru, arka uçun her isteği bağımsız olarak yetkilendirip yetkilendirmediğidir. Bir kullanıcı, kendi hesabındaki bir kimliği başka bir kimlikle değiştirdiğinde başkasının verisine erişebiliyorsa bu yatay yetki yükseltmedir (IDOR/BOLA). Standart bir kullanıcı, yalnızca istemcide gizlenmiş bir yönetici uç noktasını doğrudan çağırabiliyorsa bu dikey yetki yükseltmedir. Çok kiracılı bir SaaS'ta bir kiracının verisi başka kiracıya sızıyorsa bu kiracı izolasyonu ihlalidir; birçok ihlalin kaynağıdır. İşlev düzeyinde bazı uç noktalar yetki kontrolünü tamamen atlıyor olabilir. Bu kusurlar tarayıcılarla neredeyse hiç yakalanmaz çünkü uygulamanın rol modelini, kaynak sahipliğini ve iş kurallarını anlamayı gerektirir. Yetkilendirme testi bu modeli açıkça çıkarır ve her rol/kaynak kombinasyonunu sistematik olarak sınar; “erişebilmemesi gerekene erişebiliyor mu?” sorusunu kanıtla yanıtlar.
- IDOR/BOLA ile bir kullanıcının başka kullanıcının verisine erişmesi
- Dikey yetki yükseltmeyle standart kullanıcının yönetici işlevlerini çağırması
- Çok kiracılı mimaride bir kiracının verisinin başka kiracıya sızması
- İşlev düzeyinde eksik yetki kontrolüyle korunmasız uç noktalar
- En az ayrıcalık ilkesinin ihlaliyle aşırı geniş erişim ve veri kaybı
Bu sorunu görmezden gelmenin riski
Neyi değerlendirir ve düzeltiriz?
Yatay yetki
- IDOR/BOLA: kaynak kimliği değiştirerek başka kullanıcı verisine erişim
- Aynı roldeki kullanıcılar arası veri sınırları
- Dolaylı referanslar ve tahmin edilebilir kimlik kullanımı
Dikey yetki
- Standart kullanıcının yönetici uç noktalarına erişimi
- Rol yükseltme ve ayrıcalık kazanımı senaryoları
- Gizlenmiş ama korunmasız işlevlerin doğrudan çağrılması
İşlev/uç nokta düzeyi
- Yetki kontrolü olmayan veya tutarsız uygulanan uç noktalar
- HTTP metodu bazlı yetki atlaması (GET vs POST/PUT/DELETE)
- İş akışı adımlarının sıra dışı çağrılmasıyla yetki atlaması
İzolasyon ve ilke
- Çok kiracılı (multi-tenant) veri izolasyonu
- En az ayrıcalık (least privilege) uygunluğu
- Rol tanımlarının (RBAC) tutarlılığı ve kapsam sızıntıları
Ele aldığımız teknik alanlar
Nasıl çalışırız?
Tipik olarak neler tespit ederiz?
Aşağıdakiler illüstratif örneklerdir; gerçek müşteri verisi değildir.
Çok kiracılı yapıda kiracılar arası veri sızıntısı (örnek bulgu)
Bir kiracının kullanıcısı, istekteki kaynak kimliğini değiştirerek başka bir kiracının kayıtlarına erişebiliyordu; sunucu tarafı kiracı bağlamı doğrulanmıyordu.
ÖneriHer sorguyu oturumun kiracı bağlamıyla sınırlayın; kaynak erişimini yalnızca kimlikle değil, sahiplik ve kiracı eşleşmesiyle doğrulayın.
Dikey yetki yükseltme: standart kullanıcının yönetici işlevine erişimi (örnek bulgu)
Yönetici işlevleri arayüzde gizliydi ancak uç nokta düzeyinde yetki kontrolü yoktu; standart bir kullanıcı isteği doğrudan göndererek yönetici eylemini gerçekleştirebiliyordu.
ÖneriYetkiyi istemci gizlemeye değil, sunucu tarafı rol kontrolüne dayandırın; her hassas uç noktada rolü açıkça doğrulayın.
HTTP metodu bazlı yetki tutarsızlığı (örnek bulgu)
Bir kaynak GET ile korunuyordu ancak aynı kaynağın DELETE metodu yetki kontrolünden yoksundu; bu, yetkisiz silmeye izin veriyordu.
ÖneriYetki kontrolünü tüm HTTP metotları için tutarlı ve merkezi biçimde uygulayın; metot bazlı boşlukları test ile kapatın.
Ne teslim alırsınız, kimler için?
Ne teslim alırsınız?
- Rol/kaynak erişim matrisi ve beklenen-gerçek karşılaştırması
- Yetkilendirme bulgu kataloğu (kanıt + etki + CVSS)
- IDOR/BOLA ve yetki yükseltme senaryolarının kanıtlı gösterimi
- Çok kiracılı izolasyon değerlendirmesi (varsa)
- Önceliklendirilmiş giderme yol haritası
- Aktarım görüşmesi ve giderme sonrası yeniden test
Kimler için?
- Rol tabanlı erişim (RBAC) kullanan tüm uygulamalar
- Çok kiracılı (multi-tenant) SaaS platformları
- Admin/kullanıcı/misafir gibi çok seviyeli portallar
- Hassas veya düzenlemeye tabi veri işleyen sistemler
Bu hizmeti ne zaman düşünmelisiniz?
- Yeni roller, ayrıcalık seviyeleri veya izin modeli eklendiğinde
- Çok kiracılı mimariye geçildikten sonra
- Yeni yönetim paneli veya ayrıcalıklı işlevler devreye alınırken
- Veri koruma/gizlilik uyum gereksinimlerini karşılamak için
Yetkilendirme Testi mi, Kimlik Doğrulama Testi mi?
| Yetkilendirme Testi | Kimlik Doğrulama Güvenlik Testi | |
|---|---|---|
| Yanıtladığı soru | Kim neye erişebilir? | Kullanıcı gerçekten iddia ettiği kişi mi? |
| Öne çıkan riskler | IDOR/BOLA, yetki yükseltme, izolasyon | Kaba kuvvet, oturum, MFA, token |
| Ana yöntem | Roller arası sistematik erişim testi | Kimlik akışı ve oturum testi |
| İdeal tamamlayıcı | Kimlik doğrulama testiyle birlikte | Yetkilendirme testiyle birlikte |
Sıkça Sorulan Sorular
IDOR ve BOLA aynı şey mi?
Kaç test hesabı sağlamalıyız?
Arayüzde gizlediğimiz işlevler yeterince korunmuş sayılmaz mı?
Çok kiracılı mimarimiz için ekstra bir şey gerekir mi?
Test sırasında veri değiştirir misiniz?
RBAC kullanıyoruz, yine de gerekli mi?
Bu API güvenlik testiyle çakışır mı?
Sonuçta %100 güvenli olur muyum?
İlgili hizmetler, araçlar ve rehberler
Web Uygulama GüvenliğiAPI Güvenlik Değerlendirmesi
Web Uygulama GüvenliğiWeb Uygulama Güvenlik Değerlendirmesi
Web Uygulama GüvenliğiOWASP Top 10 Değerlendirmesi
Web Uygulama Güvenliği
Yetkilendirme Testi için başlayalım
Kapsamı netleştirelim, önceliklerinizi belirleyelim ve size özel, şeffaf bir güvenlik yol haritası çıkaralım — abartılı vaat değil, ölçülebilir risk azaltma.