Web uygulama güvenlik duvarı, bir web uygulamasına gelen istekleri inceleyerek saldırı girişimlerini engelleyen kontroldür. Klasik güvenlik duvarı ağ katmanında çalışırken, bu kontrol uygulama katmanındaki istek içeriğini değerlendirir. Enjeksiyon girişimleri, betik çalıştırma denemeleri ve dosya yükleme istismarları bu katmanda yakalanabilir. Kontrol, uygulamanın önüne yerleştirilir ve trafiği süzer. Bulut tabanlı ya da şirket içi olarak konumlandırılabilir. İki model de yaygındır.

Kontrolün en önemli değeri, uygulamada bir zafiyet bulunsa bile sömürüyü zorlaştırmasıdır. Bu nedenle telafi edici bir kontrol olarak değerlendirilir. Yamanın hemen uygulanamadığı durumlarda geçici koruma sağlar. Buna karşılık kök nedeni ortadan kaldırmaz. Zafiyetin düzeltilmesi yine gereklidir. Bu ayrım net tutulmalıdır.

Web Uygulama Güvenlik Duvarı Nedir?

Web uygulama güvenlik duvarı, web uygulamasına gelen istekleri kural setine göre inceleyerek saldırı girişimlerini tespit eden ve engelleyen uygulama katmanı kontrolüdür.

Kontrol iki modda çalışabilir. İzin listesi modunda yalnızca tanımlı ve beklenen istekler geçirilir; bu mod güvenlidir ama uygulamanın ayrıntılı bilinmesini gerektirir. Kara liste modunda ise bilinen saldırı desenleri engellenir; uygulaması kolaydır ama bilinmeyen teknikleri kaçırır. Pratikte çoğu kurulum ikinci modu kullanır. Karma yaklaşım da mümkündür. Kritik uç noktalarda izin listesi tercih edilir.

Hangi Saldırıları Engeller?

En yaygın kullanım, enjeksiyon saldırılarının engellenmesidir. SQL enjeksiyonu ve komut enjeksiyonu girişimleri, karakteristik desenler taşıdığı için tespit edilebilir. İkinci grup, betik çalıştırma denemeleridir. Üçüncü grup, dosya yolu istismarları ve yükleme girişimleridir. Dördüncü grup ise otomatik tarama ve kaba kuvvet denemeleridir. Bu son grup hız sınırlamayla ele alınır.

Kontrol ayrıca bilinen zafiyetlere yönelik özel kurallar da barındırabilir. Yaygın kullanılan bir bileşende kritik bir zafiyet duyurulduğunda, üretici hızlıca sanal yama yayımlar. Bu kural, yama uygulanana kadar koruma sağlar. N-day saldırıları penceresinde bu koruma değerlidir. Yine de kalıcı çözüm yamadır. Sanal yama geçicidir.

• Enjeksiyon ve betik çalıştırma girişimleri
• Dosya yolu istismarı ve yükleme denemeleri
• Otomatik tarama ve kaba kuvvet trafiği
• Bilinen bileşen zafiyetlerine yönelik sanal yama
• Bot trafiğinin ayrıştırılması ve hız sınırlama

Sınırları

En temel sınır, iş mantığı zafiyetlerini görememesidir. Yetkilendirme eksikliği ya da süreç akışındaki bir kusur, isteklerde herhangi bir saldırı deseni üretmez. Bu istekler tamamen normal görünür ve geçirilir. İş mantığı zafiyetleri bu nedenle bu katmanda ele alınamaz. Çözüm uygulama tarafındadır. Kod düzeltmesi gerekir.

İkinci sınır, atlatma tekniklerinin varlığıdır. Kodlama değişiklikleri, parçalanmış istekler ve alışılmadık biçimlendirmeler kural eşleşmesini bozabilir. Bu nedenle kural setinin güncel tutulması gerekir. Ayrıca kontrolün doğru normalleştirme yapması önemlidir. Ürün seçiminde bu yetenek değerlendirilir. Test edilmelidir.

Üçüncü sınır, yanlış pozitif riskidir. Katı kurallar meşru istekleri engelleyerek uygulamayı kullanılamaz hâle getirebilir. Bu nedenle devreye alma izleme modunda yapılır ve kurallar rafine edilir. Bu süreç haftalar sürebilir. Sabır gerektirir. Aceleci geçişler geri alınır.

Yapılandırma ve Yönetim

Devreye alma, izleme modunda başlamalıdır. Bu dönemde hangi kuralların hangi isteklerle eşleştiği incelenir ve istisnalar tanımlanır. Ardından kritik kurallar engelleme moduna alınır. Kademeli geçiş, kesinti riskini azaltır. Uygulama ekibiyle birlikte yürütülmelidir. İş birliği gereklidir.

Kayıtların incelenmesi de sürecin parçasıdır. Engellenen istekler, uygulamaya yönelik saldırı girişimlerini gösterir. Bu bilgi, uygulamanın hangi yönlerden hedef alındığını ortaya koyar. Ayrıca zafiyet önceliklendirmesine girdi olur. Kayıtlar merkezî toplanmalıdır. Cihaz üzerinde saklanan kayıtlar sınırlıdır.

Konumlandırma Seçenekleri

Kontrol, uygulamanın önünde ters proxy olarak, ağ üzerinde köprü modunda ya da bulut hizmeti olarak konumlandırılabilir. Bulut modelinde trafik önce sağlayıcının altyapısına gider ve orada süzülür. Bu model, hacimli saldırılara karşı da koruma sağlar ve kurulum yükü azdır. Şirket içi model ise veri egemenliği ve gecikme açısından tercih edilebilir. Seçim, kurumun kısıtlarına göre yapılır. İki model de yaygındır.

Bulut modelinde kaynak sunucunun doğrudan erişilebilir olmaması sağlanmalıdır. Aksi hâlde saldırgan koruma katmanını atlayarak sunucuya doğrudan bağlanabilir. Bu boşluk sık görülen bir yapılandırma hatasıdır. Kaynak sunucu yalnızca sağlayıcı adreslerinden erişilebilir olmalıdır. Bu kısıtlama ağ katmanında uygulanır. Doğrulama yapılmalıdır.

Gerçek istemci adresinin uygulamaya iletilmesi de yapılandırılmalıdır. Aksi hâlde uygulama kayıtlarında tüm istekler koruma katmanının adresinden geliyormuş gibi görünür. Bu durum, olay incelemesini imkânsız kılar. İlgili başlıkların doğru yapılandırılması gerekir. Ayrıca bu başlıkların taklit edilemez olması sağlanmalıdır. Güvenlik açısından önemlidir.

Kural Bakımı

Kural setinin uygulamaya göre uyarlanması gerekir. Genel kural setleri geniş kapsama sunar ama uygulamanın özgün davranışlarını bilmez. Bu nedenle devreye alma sonrası istisna tanımlama süreci yürütülür. İstisnaların belgelenmesi ve dönemsel gözden geçirilmesi şarttır. Belgesiz istisnalar zamanla korumayı zayıflatır. Disiplin gereklidir.

Uygulama değiştikçe kuralların da gözden geçirilmesi gerekir. Yeni bir uç nokta eklendiğinde ya da istek yapısı değiştiğinde mevcut kurallar uyumsuz kalabilir. Bu nedenle sürüm çıkışları kural gözden geçirmesini tetiklemelidir. Süreç geliştirme akışına bağlanır. Otomasyon mümkündür. Entegrasyon değerlidir.

Privia Security olarak web uygulamalarının hem kod hem koruma katmanındaki durumunu düzenli zafiyet tarama hizmeti kapsamında değerlendiriyoruz.