Örnek sorular
As Access Control IdorZorluk 1
"Broken access control" (bozuk erişim kontrolü) bir güvenlik açığı kategorisi olarak ne anlama gelir?
- aGiriş formu parola biçimini yeterince sıkı doğrulamıyor
- bGiriş sayfasındaki TLS sertifikasının süresi dolmuş
- cKimliği doğrulanmış bir kullanıcı, erişmemesi gereken veri veya işlevlere erişebiliyor✓
- dVeritabanı bağlantı havuzu yük altında tükenir ve bu tüm uç noktalarda aralıklı zaman aşımlarına neden olur.
Açıklama:Broken access control, sistemin çağıranın kim olduğunu doğru bildiği ama o çağıranın neyi okuyup neyi değiştirebileceğini doğru şekilde kısıtlayamadığı durumları tanımlar — bu nedenle son dönemlerde OWASP Top 10 listesinde ilk sırada yer alır.
As Access Control IdorZorluk 2
Bir fatura detay sayfasına /invoices/482 üzerinden ulaşılıyor. Giriş yapmış bir kullanıcı URL'yi /invoices/481 yapınca başka bir müşterinin faturasını görüyor. Buradaki temel kusur nedir?
- aFatura numaraları URL'de şifrelenmemiş
- bSunucu, 481 numaralı faturayı döndürmeden önce isteği yapan kullanıcının bu faturanın sahibi olup olmadığını kontrol etmiyor✓
- cOturum çerezinde
Secure bayrağı eksik - dFatura ID'leri rastgele string yerine ardışık tamsayı, bu tek başına kimliği doğrulanmış herhangi bir kullanıcının her faturayı numaralandırmasına izin verir.
Açıklama:Bu, klasik bir Insecure Direct Object Reference (IDOR) örneğidir: sunucu istekteki ID'ye güvenip eşleşen satırı getiriyor ama doğrulanmış kullanıcının o kayıtla sahiplik ilişkisini kontrol etmiyor. ID'leri ardışık olmaktan çıkarmak yalnızca belirsizlik ekler, eksik sahiplik kontrolünü düzeltmez.
As Access Control IdorZorluk 2
Yatay (horizontal) ve dikey (vertical) yetki yükseltme arasındaki fark nedir?
- aYatay, aynı yetki seviyesindeyken başka bir kullanıcının verisine erişmektir.✓
- bYatay, admin hakları kazanmaktır; dikey, başka bir kiracının satırlarını okumaktır
- cİkisi aynı saldırıyı farklı satıcıların farklı isimlendirmesidir
- dYatay yalnızca REST API'lere, dikey yalnızca GraphQL API'lere uygulanır
Açıklama:Yatay yükseltme, normal bir kullanıcının başka bir normal kullanıcının kaynaklarına ulaşmasıdır (aynı seviye, yanlış sahip) — fatura örneğindeki gibi. Dikey yükseltme ise normal bir kullanıcının, sıradan bir kullanıcının admin'e özel bir uç noktayı çağırması gibi daha yüksek bir role ayrılmış işlevselliğe ulaşmasıdır.
As Access Control IdorZorluk 1
Admin olmayan kullanıcılar için frontend'de bir "Admin Ayarları" butonunu gizlemek neden tek başına gerçek bir erişim kontrolü mekanizması değildir?
- aÇünkü frontend kodu koşullu arayüz hiç render edemez, bu yüzden gizli bir öğe bir tasarım tercihi değil bir render hatasıdır.
- bÇünkü altta yatan API uç noktasına doğrudan erişilebilir.✓
- cÇünkü her tarayıcı CSS
display:none'ı yok sayar - dÇünkü gizli butonlar tarayıcı render hatasına yol açar
Açıklama:Arayüzde gizleme bir kullanılabilirlik ayrıntısıdır, güvenlik sınırı değildir — herhangi bir istemci butonu tamamen atlayarak arka uç uç noktasını doğrudan (devtools, curl veya bir proxy ile) çağırabilir. Asıl yetkilendirme kararı, her istekte sunucu tarafında uygulanmalıdır.
As Access Control IdorZorluk 2
Bir SaaS ürünü tüm müşterilerin verisini tenant_id kolonlu tek bir paylaşımlı orders tablosunda tutuyor. Bir hata, bir uç nokta için sorgudan WHERE tenant_id = ? filtresinin düşmesine yol açıyor. Bunun doğrudan sonucu nedir?
- aSorgu performansı düşer ama veri izolasyonu korunur
- bYalnızca okuma işlemleri etkilenir, yazmalar varsayılan olarak izole kalır
- cVeritabanı, her tablonun kiracıya foreign key'i olduğu için kiracı izolasyonunu otomatik olarak uygular.
- dBir kiracının isteği başka bir kiracıya ait satırları döndürebilir veya etkileyebilir✓
Açıklama:Paylaşımlı-şema çoklu-kiracı tasarımında izolasyon tamamen uygulama sorgu mantığında (ya da veritabanı seviyesinde satır güvenliğinde) yaşar — kiracı filtresi olmayan bir sorguyu başka hiçbir mekanizma durdurmaz, bu doğrudan kiracılar arası veri sızıntısıdır ve yazma işlemlerini de okuma kadar kolay etkileyebilir.
As Access Control IdorZorluk 1
Role-Based Access Control (RBAC) yönteminde bir isteğin izin verilip verilmeyeceğini ne belirler?
- aİsteğin yapıldığı günün saati
- bİsteğin iç bir IP adresinden gelip gelmediği
- cKullanıcının parolasının uzunluğu
- dKullanıcıya atanan rol(ler) ve o rolün gereken izne sahip olup olmadığı✓
Açıklama:RBAC izinleri rollere verir, roller de kullanıcılara atanır; erişim kararı, isteği yapan kullanıcının sahip olduğu rollerden herhangi birinin ilgili işlem için gereken izni içerip içermediğine bakar, tekil kullanıcı özniteliklerini değerlendirmez.