Uygulamalar uzun süredir monolitik yapılardan karmaşık, bulutta yerel mimarilere doğru evrildi. Bu, güvendiğimiz denenmiş ve doğrulanmış yöntemlerin tehlikeli bir şekilde güncelliğini yitirdiği anlamına geliyor. AppSec’in buna ayak uydurması için mevcut araçların ötesine bakmalı ve otomatik kara kutu testi disiplini olan DAST’ın temellerini yeniden gözden geçirmeliyiz.
Kara kutu güvenlik testinin temelleri
Modern zorluklara dalmadan önce, başarılı bir kara kutu güvenlik testinin üç sütununu tekrar gözden geçirelim: teknoloji değişse bile sabit kalan bir temel:
- Durum: Uygulamanın potansiyel güvenlik açıklarını açığa çıkaracak belirli bir duruma getirilmesi gerekir.
- Yükler: Güvenlik açığının tetiklenmesi için ilgili saldırı dizesinin gönderilmesi gerekir. Yüklerin, temel teknolojilere ve istenen saldırganlığa uyacak şekilde hazırlanması gerekir (örneğin, basit bir SLEEP ve verileri değiştiren bir DELETE).
- İddialar: Yükün başarılı olup olmadığını belirlemek için güvenilir bir yola ihtiyacınız var. Bu, bir komut dosyası uyarısı(1) kadar basit veya Kör SQL enjeksiyonu için yanıt süresi değişikliklerini ölçmek kadar karmaşık olabilir.
Bu temeller her zaman iki ana kaynak tarafından kısıtlanır:
- Sunucu yükü: Sistem (özellikle üretim sistemi) test yükünü kaldırabilir mi? Üretimin test edilmesi genellikle idealdir çünkü iş açısından kritik tüm verileri içerir ve asla gerçek anlamda sahnelemeye eşit değildir.
- Tarama süresi ve maliyeti: Kaynaklar sınırlıdır. Hızlı derleme hattında çalışan bir tarama, QA ortamındaki taramadan farklı bir zaman bütçesine ihtiyaç duyar. Ayrıca işleme, trafik ve hatta AI belirteçlerinin hesaplama maliyetlerinin de hesaba katılması gerekir.
Eski yöntemler neden bozuluyor?
Kara kutunun temelleri kararlıdır ancak test ettiğimiz uygulamalar tamamen devrim niteliğindedir.
Monolitik eski mimari (“eski güzel günler”)
Geleneksel LAMP yığını dünyasında işler daha basitti:
- URL = Durum: Uygulamanın her durumuna bir URL aracılığıyla doğrudan erişilebiliyordu.
- Görünür teknoloji: Temel teknoloji yığınını belirlemek nispeten kolaydı ve alternatifler azdı.
- Doğrudan yük yanıtı: Yükler, sistem bileşenlerinde minimum hareketle, test ettiğiniz uygulamayı doğrudan tetikledi.
Modern Uygulama Mimarisi
Günümüzde mimari karmaşık ve katmanlı olup tüm eski varsayımları yıkmaktadır:
- URL ≠ Durum: Uygulama durumu artık yalnızca URL’ler tarafından değil, eylemler (bir ürünü sepete eklemek için bir düğmeye tıklamak gibi) tarafından yönlendiriliyor. Modern URL’ler genellikle parçalar (#) kullanır ve HTTP isteklerini tetiklemeden JavaScript geçmişi API’si aracılığıyla istemci tarafını değiştirebilir.
- Gizli teknoloji yığını: Uygulamalar artık CDN’lerden, bulut depolama alanından, konteyner gruplarından, mesaj kuyruklarından (Kafka gibi) ve zamanlayıcılardan oluşuyor. Temel teknoloji birçok katmanın arkasında gizlenir ve korunur.
- Yükler bileşenler arasında tetiklenir: Tek bir veri yükü, Kafka mesaj veri yolu üzerinden seyahat edebilir ve potansiyel olarak kodlama dilleri arasındaki serileştirme/seri durumdan çıkarma farklılıklarından veya hatta üçüncü taraf bir hizmetten (örneğin bir günlük kaydı aracı) dolayı ayrı bir sistemde tetiklenebilir.
Mimari temelden değiştikçe, genellikle onlarca yıllık temel projelere dayanan birçok kara kutu aracının buna ayak uydurmak için mücadele etmesi şaşırtıcı değil.
Kara kutu metodolojisinde (çok) gerekli değişiklikler
Modern uygulamaların zorluklarının üstesinden gelmek için kara kutu araçlarının duruma, yüklere ve iddialara yönelik yaklaşımlarını geliştirmesi gerekir.
1. Oluşturma Durumu
- Grafik, ağaç değil: URL ağaçları eskidir. Modern bir web uygulaması şu şekilde modellenmelidir: grafikBir düğümün bir durum olduğu ve bir kenarın, durumu değiştiren bir eylemin eğitimli bir tahmini olduğu durumlarda. Bu, hem istemci tarafı hem de sunucu tarafı durumunun modellenmesini gerektirir.
- Devletin rekreasyonu: Artık yalnızca bir URL veya HAR arşivi ile bir durumu güvenilir bir şekilde yeniden oluşturamazsınız. Araçlar, belirli bir duruma ulaşmak için gerçekleştirilen eylemlerin sırasını tekrar oynatır.
- Kısa ömürlü durumlar: Durumlar giderek daha kısa ömürlü hale geliyor (örneğin, kısa TTL’li JWT’ler), bu da geleneksel tarayıcıların bunları daha sonra etkili bir şekilde test etmesini zorlaştırıyor.
2. Yüklerin hazırlanması
- Bağlama duyarlı yükler: Tüm yığın gizlendiğinden, yüklerin çalışacak şekilde tasarlanması gerekir. çoklu bağlamlar. Tek bir dize, sistem boyunca yayıldıkça ve potansiyel olarak farklı bir yazılım yığınında tetiklendiğinde, farklı programlama dilleri arasında serileştirme/seri durumdan çıkarma işleminden sağ çıkmalıdır.
3. İddialarda Bulunmak
- Gecikmeli ve bant dışı tetikleyiciler: Yükler artık çok daha sonra, muhtemelen işlenmek üzere kuyruğa alındıktan veya farklı bir görünümden geri döndürüldükten sonra tetiklenebilir. Log4j güvenlik açığı, mimarinin derinliklerinde tetiklenen, bant dışı yöntemler ve ağ geri pingleri gerektiren yüklerin açık bir örneğiydi.
- Gürültülü Sistemler: Kör SQL enjeksiyonu için yanıt süresini kullanmak gibi sistem davranışlarını ölçmek, mesaj kuyruklarına ve yük dengelemeye dayalı bir mimaride neredeyse imkansızdır.
İleriye giden yol
Önemli olan “her şeyi yapay zekayla yapmak” değil, karar almayı optimize etmek için gelişmiş yöntemleri stratejik olarak kullanmaktır. Biz Detectify olarak bu sorunu çözmek için API Tarayıcımız için temel bir örnek olarak Dinamik Yük Yükü Rotasyonu ile birkaç yeni nesil değerlendirme güncellemesi sunmaya başladık ve çok daha fazlasının gelecek yılın başlarında planlanması planlanıyor.
Bu özellik, sürekli kontrolleri deneysel varyasyonlarla birleştirerek neredeyse sonsuz bir yük havuzundan yararlanır. Deneysel bir veri yükü başarılı olursa söz konusu teknoloji yığını için gelecekteki testlerde hemen yeniden kullanılır. Denetimsiz makine öğreniminin bu biçimi, tarayıcının kalıcı bir test avantajı elde etmesine olanak tanıyarak durum, yük ve iddia temellerinin korudukları uygulamalar kadar hızlı gelişmesini sağlar.