Sistematik bir metodoloji, hiyerarşik miras için matris tabanlı izin testleri ile birlikte sınır değer analizi gerektirir. Bu yaklaşım, rol kombinasyonlarının ve bunların etkili izinlerinin kapsamlı bir şekilde incelenmesini sağlar. Oturum bağlamı geçişi doğrulaması, kullanıcı ayrıcalıklarının farklı kurumsal alanlar arasında gezinirken doğru bir şekilde güncellenmesini sağlamalıdır.
Her rol kombinasyonunu veri nesneleri ve alanlar ile eşleştiren bir izin matrisini oluşturarak başlayın, junior rollerin üst rollerden izinleri topladığı miras zincirlerini tanımlayın. Yatay ayrıcalık yükseltme testleri gerçekleştirerek, manipüle edilmiş tanımlayıcılar kullanarak aynı kiracı içindeki akranlara ait kaynaklara erişmeye çalışın. Sonra, daha düşük ayrıcalık seviyesine sahip kullanıcıların yönetimsel yetkilere ulaşmak için miras yollarını istismar edemeyeceklerini doğrulamak amacıyla rol hiyerarşisini aşarak dikey yükseltme testleri yapın.
Alan seviyesinde güvenlik için, çift kanallı doğrulama uygulayın: Hassas alanların null edildiğinden veya hashlenmiş olduğundan emin olmak için REST uç noktalarından gelen JSON yanıtlarını inceleyin. Daha sonra React bileşenin yeniden render edildiği durumlarda maskenin devam ettiğini doğrulamak için DOM renderlamasını kontrol edin. Bu, API'nin veri sızdırdığı durumda UI görünümünün güvenli görünmesini önler.
Kiracılar arası izolasyonu doğrulamak için, tek bir tarayıcının birden fazla kiracı bağlamında aktif oturumları koruduğu eşzamanlı oturum testleri gerçekleştirin. localStorage, IndexedDB ve Redux mağaza ayrımının, kuruluş görüntüleri arasında geçiş yaparken veri sızıntısını önlediğini doğrulayın. Asenkron izin kontrolü tamamlanmadan önce bağlamları hızla değiştirme yoluyla önbellek zehirlenmesi test edin.
Bağlam ve Problem Açıklaması
Birden fazla kliniği ayrı kiracılar olarak hizmet veren bir sağlık yönetim platformunu test ederken, Clinic A'daki "Danışman" rollerine ve Clinic B'deki "Başhekim" rollerine sahip doktorların, Klinik A'nın daha katı HIPAA uyumluluk kurallarına göre tamamen gizlenmiş olması gereken Klinik B'deki kısmen maskelenmiş hasta SSN alanlarını görebileceği kritik bir güvenlik boşluğu ile karşılaştım. Sorun, kullanıcıların tek bir tarayıcı oturumu içinde organizasyonlar arasında geçiş yaptıklarında özellikle ortaya çıkıyordu; bu, kiracı verisi alanları arasında önbellek kirliliği veya bağlam sızması olduğunu gösteriyordu. Ayrıca, React ön yüzü maskelenmiş değerleri gösterirken, API ağ sekmesinde tam olarak maskelenmemiş SSN'leri sızdırıyordu, bu da yanlış bir güvenlik hissi yarattı ve potansiyel düzenleyici ihlale neden oldu.
Çözüm 1: Otomatik RBAC Doğrulama Scriptleri
Bir yaklaşım, rol geçişini otomatikleştirmek ve yüzlerce izin kombinasyonu arasındaki alan görünürlüğünü doğrulamak için Selenium scriptleri yazmaktı. Bu, kapsamlı bir kapsama ve regresyon testleri için hızlı bir yürütme sundu. Ancak, scriptler sadece ön uç metin içeriğini doğruladığından, belirli UI/API senkronizasyonu sorununu tespit edemedi. Hızla gelişen rol hiyerarşilerini sürdürmek, iki haftalık bir sprint döngüsü için sürdürülebilir olmadı.
Çözüm 2: Yönetici Ayrıcalıklarıyla Ad-hoc Keşif Testi
Düşünülen bir başka yöntem, çeşitli kullanıcı senaryolarını manuel olarak kontrol etmek için süper yönetici hesapları ile yapılandırılmamış keşif testleri yapmaktı. Bu, şüpheli davranışları araştırmak için hemen esneklik sağlasa da, izin mirası matrisinin sistematik kapsamını kaybetmişti ve üç seviye rol hiyerarşisi içeren kenar durumlarını kaçırmıştı. Ad-hoc testlerin rastgeleliği nedeniyle, çapraz kiracı misafir erişimi ve alan seviyesinde maskeleme kombinasyonunun test edildiğinden emin olamadık.
Seçilen Çözüm: Oturum İzolasyon Protokolleri ile Sistematik Matris Testi
Her bir ana rol, miras alınan izinler ve kiracılar arası misafir erişimi için her permütasyonu belgeleyen yapılandırılmış bir test matrisini uyguladım. Her test durumu için, Chrome DevTools kullanarak Ağ sekmesi yanıtlarını izledim ve bileşen özelliklerini incelemek için React Developer Tools kullandım, API ve UI maskeleme tutarlılığını sağladım. Redux durumu hala hidrat edilirken organizasyon açılır menüsünü kullanarak kiracı bağlamları arasında hızlıca geçiş yaparak yarış koşullarını test ettim. Veri sızıntısını önlemek için kiracı izolasyonunu sağlamak amacıyla localStorage anahtar ön eklerini doğruladım.
Bu çözüm neden seçildi
Bu yaklaşım, kapsamlı kapsama ile manuel doğrulama için gerekli çevikliği dengeledi. Otomatik scriptlerin gözden kaçırabileceği veri akışlarını gerçek zamanlı olarak denetlemeye izin verdi ve çok kiracı mimarilere özgü kiracı oturum yönetimi karmaşıklığını özellikle hedef aldı. Metodoloji, GraphQL çözümleyicisinin, erişilen ilk kiracıya dayalı alan seviyesinde yetkilendirme kararlarını önbelleğe aldığını ortaya çıkardı.
Sonuç
Test, kullanıcının Clinic A'ya geçtiğinde Apollo Client önbelleğinde açık SSN değerleri saklayan kritik bir güvenlik açığını ortaya çıkardı ve bu durum HIPAA ihlallerine neden oldu. Ayrıca, misafir erişimi geri alındığında miras alınan izinlerin tekrar hesaplanmadığını ve JWT token önbelleklemesi nedeniyle 24 saat boyunca hayalet izinlerin aktif kaldığını belirledik. Her iki sorun da P0 hata olarak yükseltildi, bu da API geçit katmanında React ön yüzüne ulaşmadan önce yanıtları kesen kiracıya özgü önbellek geçersiz kılmaları ve alan seviyesi güvenliği ara yazılımının uygulanmasına yol açtı.
Dikey ayrıcalık yükseltme açıklarını REST API'lerinde tanımlamak için peş peşe tam sayılar yerine nesne tanımlayıcıları hashlenmiş veya UUID tabanlı olduğunda nasıl tespit edersiniz?
Adaylar genellikle peş peşe kimlik manipülasyonuna dayanıyor, ancak modern sistemler UUID kullanıyor. Doğru yaklaşım, aynı kiracı içinde farklı izin seviyelerine sahip iki ayrı kullanıcı hesabı oluşturmak ve ardından bu hesaplar arasında JWT token veya oturum çerezlerini değiştirirken kaynaklara erişmeyi denemektir. Kullanıcı A'dan meşru API isteklerini yakalayın, ardından bu istekleri Kullanıcı B'nin kimlik doğrulama başlıklarını kullanarak tekrar oynatın, böylece yetkilendirme ara yazılımının tanımlayıcıların tahmin edilebilirliğinden bağımsız olarak çapraz kullanıcı erişimlerini doğru bir şekilde reddettiğini doğrulayın. Ayrıca, diğer kullanıcıların kaynak kimliklerini değiştirme yoluyla IDOR (Güvensiz Doğrudan Nesne Referansı) test edin.
Manuel QA'da kimlik doğrulama ile yetkilendirme arasındaki temel fark nedir ve neden karıştırılması güvenlik açıklarına yol açar?
Kimlik doğrulama, giriş akışları, MFA veya SSO entegrasyon testleri aracılığıyla kimlikleri doğrulayarak gerçekleştirilirken, yetkilendirme izinleri doğrular. Adaylar genellikle, bir kullanıcının giriş yapmadığı sürece yönetici sayfasına erişemeyeceğini test ederek (kimlik doğrulama) bunları karıştırırken, standard bir kullanıcının kimlik doğrulamasından sonra bile yönetici sayfasına erişmemesi gerektiğini göz ardı ederler (yetkilendirme). Kapsamlı manuel testler, bir kimlik doğrulama ve diğeri izin uygulamaları için ayrı test takımları gerektirir. Kritik boşluk, test uzmanlarının başarılı bir kimlik doğrulamanın doğru yetkilendirmeyi ifade ettiğini varsayıp Kırık Erişim Kontrolü gibi hataları gözden kaçırdığı durumlarda ortaya çıkar.
İptal edilen veya geçersiz kılınan izinlerin, doğal token süresinin dolmasını beklemeden önbellekteki istemci tarafı depolama alanlarında veya JWT tokenlarında kalmadığını nasıl doğrularsınız?
Çoğu aday, izin iptal edildikten hemen sonra UI'yi kontrol eder ve menü öğelerinin kaybolmasının sistemin çalıştığına dair yanlış bir sonuç çıkararak bunun doğru olduğunu varsayar. Ancak, JWT tokenları içinde yerleşik izin iddiaları içerir ve bunlar süresi dolana kadar geçerlidir; localStorage kullanıcı meta verilerini önbelleğe alabilir. Doğru metodoloji, Kullanıcı A olarak oturum açmak ve localStorage'dan JWT tokenını yakalamak, ardından yönetim panelinde Kullanıcı A'dan belirli bir izni iptal etmektir. İhlal edilen işlemi önceki JWT tokenı ile bir Postman isteği göndererek veya tarayıcının localStorage'ında tokenı yeniden enjekte ederek gerçekleştirmeyi deneyin, böylece API'nin 200 OK yerine 403 Yasaklı döndürdüğünü doğrulayın.