IIS için baykuş, SQL'leri çalışma zamanında yürütülmeden hemen önce tanımlar. Bu, Runtime Application Self-Protection (RASP) modülünü uygulayarak.
Web uygulamanız, sorgu ve gönderim parametreleri yoluyla girdi alıyor. Girdi, çapraz site komut dosyası oluşturma, SQL enjeksiyonu ve diğer güvenlik ihlalleri oluşturabilir. Şimdiye kadar WAF'nin süreçte değil ağda kısıtlamaları olduğunu biliyoruz: 1. Trafik şifrelendiğinde bazıları SSL anahtarlarına bağımlı olabilir. Bu DH durumu 2'yi işleyemez. Süreç, SQL'leri çalıştırmak için farklı bir kullanıcıyı kullanabileceğinden hangi kullanıcının hangi SQL ifadelerinden sorumlu olduğundan emin olamazsınız. Gelişmiş URL değiştirme, WAF'yi kandırabilir 4. Geliştirici uygulamada bir arka kapı belirleme. (Nihai olarak kötü niyetli kod çalıştırmak için ekstra sorgu parametresi tarafından etkinleştirilir). WAF bunu nasıl anlayabilir?
Şu örneği alın: kullanıcı tarayıcısı, bölüm http: //applicationHost/getData.aspx? Code = derpatment içindeki kullanıcıların bir listesini almak için bu HTTP isteğini gönderiyor. Ancak kullanıcı el ile http: //applicationHost/getData.aspx? Code = company gibi farklı bir kod değerine değiştirebilir. Buna ek olarak, SQL'lerin bazı jenerik kullanıcıları kullanarak kimliği doğrulanmış bir iş parçacığı havuzu tarafından yürütülmekte olduğunu söylüyoruz. 1. Veritabanı aracı istekte kimlerin olduğunu söyleyemez. 2. URL'de bir şeylerin olup olmadığını anlamak için WAF'in karmaşık olması gerekir.
Uygulamanın yürüttüğü tam SQL deyimi ile kullanıcı ayrıntılarını (ad ve IP) ilişkilendirmeniz gereken tek seçenek, Uygulamanın SQL deyimini sürecin dışına gönderdiği noktada. Uygulama, giriş işlemini tamamladıktan sonra gerçek SQL'dir. Sezgisel değil, yanlış pozitif değil. IIS için baykuş, bu sürümde tüm SQL ifadelerini göstermeyi hedefliyor.
Yenilikler :
Sürüm 1.3:
- denetim dosyası şimdi kullanıcı adını içeriyor
- uygulama kullanıcı adını iletmek için IBM Guardium ile entegrasyon
Yorum Bulunamadı