Kimlik Doğrulamalı DAST: Kapsamı, Test Hesaplarını ve Güvenli Sınırları Belirleme

Kimlik doğrulamalı dinamik uygulama güvenliği testi (DAST), anonim taramanın göremediği iş akışlarına erişebilir: hesap ayarları, faturalar, yönetim işlemleri ve tenant’a özel API’ler. Aynı oturum, kapsam ve durum değiştiren davranışlar önceden kararlaştırılmadıysa taramayı kesintiye de uğratabilir.

Güvenli plan, yetkiyi test yapılandırmasının bir parçası sayar. Kimlik bilgileri tarayıcıya verilmeden önce değerlendirmede hangi uygulama, hesap, veri ve işlemlerin kullanılabileceğini; sınırın aşıldığının nasıl anlaşılacağını belirleyin.

Kapsamı açık kurallar olarak tanımlayın

İzin verilen protokolü, host adlarını, portları, ortamları ve URL öneklerini yazın. Kimlik sağlayıcıya, ödeme işlemcisine, nesne depolamaya veya diğer alan adlarına yönlendirmelerin kapsam dışında olup olmadığını belirtin. Kapsamdaki bir sayfadan bağlantı verilmesi, hedefi otomatik olarak test iznine dahil etmez.

Hesap silme, toplu mesaj gönderme, ödeme alma, üretim verisi dışa aktarma ve geri alınamayan yönetim işlemleri gibi yıkıcı veya yüksek etkili rotaları hariç tutun. Bir yetkilendirme kararını test etmek için bu rota gerekiyorsa, önce güvenli bir test verisi ya da üretim dışı karşılık üzerinde anlaşın. İzin verilen ve hariç tutulan hedefleri operatörlerin ve inceleyicilerin kolayca bulabileceği yerde tutun.

Amaca uygun kimlik ve veri kullanın

Her rol ve tenant sınırı için ayrı test hesapları oluşturun. Hesaplara yalnızca senaryo için gereken yetkileri verin; çalışanların kişisel girişlerini veya ortak yönetici hesabını kullanmayın. Yetkili ve yetkisiz erişimi müşteri verisi açığa çıkarmadan ayırt edebilmek için ortamda sentetik kayıtlar kullanın.

Her kimliğin rolünü, tenant’ını, veri sahipliğini ve beklenen izinlerini kaydedin. Yararlı bir yetkilendirme testi iki kullanıcının davranışını karşılaştırır: A hesabı kendi kaydını ister, sonra aynı işlemi B hesabının kaydı için dener. Kanıt gerçek başka bir kullanıcının içeriğini değil, politika sınırını ve sonucu göstermelidir.

Kimlik doğrulamayı bilinçli yapılandırın

Giriş akışını, oturum süresini, MFA gereksinimlerini, CSRF korumasını ve token yenileme davranışını belgeleyin. Değerlendirmenin önceden doğrulanmış bir oturumla mı başlayacağını yoksa giriş akışını da mı test edeceğini kararlaştırın. Tarama ortasında oturum sona ererse tarayıcı giriş sayfasını başarılı uygulama yanıtı sanabilir veya oturum gerektiren rotaları kaçırabilir.

Kimlik bilgilerinin nerede saklandığını, kimin erişebildiğini ve ne zaman kaldırıldığını gözden geçirin. Mümkünse geçici ve en az yetkili kimlik bilgileri kullanın. Uzun süreli sırları ekran görüntülerine, dışa aktarılan raporlara veya iş kayıtlarına koymayın. Tarama derinliğini artırmadan önce oturum süresi dolduğunda aracın nasıl davrandığını sınayın.

Durum değişikliklerini ve istek hacmini kontrol edin

İstek hızı sınırlarını, tarama zamanını ve testi durdurabilecek kişiyi belirleyin. Veri oluşturan veya değiştiren işlemleri tespit edip hariç tutma, simüle etme ya da yalnızca atılabilir test verisiyle çalıştırma kararı alın. Arayüzde “salt okunur” yazması yeterli değildir; uygulama yan etki olarak veri yazabilir.

Dar bir profil ve küçük bir hedefle başlayın. Derinliği artırmadan veya yeni modüller açmadan önce kimlik doğrulamayı, kapsamı, yönlendirme davranışını ve kanıt yakalamayı doğrulayın. Beklenmeyen yükü, yinelenen bildirimleri, kilitlenen hesapları ve oluşturulan kayıtları izleyin. Gözlenen davranış planın dışındaysa durup yeniden değerlendirin.

Durdurma koşullarını ve kapanışı ölçülebilir yapın

Testten önce durdurma koşullarını yazın: beklenmeyen üretim etkisi, kapsam dışı veriye erişim, yinelenen kimlik doğrulama hataları, hız sınırı uyarıları veya onaylanmamış hedefe callback. Kimin bilgilendirileceğini ve duraklamadan sonra testin nasıl devam edeceğini belirleyin.

İş bitince geçici kimlik bilgilerini iptal edin, uygun olduğunda test kayıtlarını silin ve bulguları onaylı kapsamla karşılaştırın. Her doğrulanmış sorun için ilgili HTTP alışverişini ve kimlik bağlamını saklayın, düzeltme sorumlusu atayın ve kapanışı kanıtlayacak isteği ya da politika kararını belirtin. Retest’i yalnızca kararlaştırılan hedef ve işlemde yapın.

Eresus Guard DAST iş akışı yetkili bir proje ve hedefle başlar; kimlik doğrulama ve değerlendirme yapılandırmasını çalışmaya bağlar, HTTP ve OAST kanıtını bulguların yanında tutar. Guard değerlendirmelerinde kapsam ve güvenlik rehberi operasyonel referans olmalıdır.