Klasik asp.net olarak da bilinen asp.net web forms güncelliğini yitirmeye başlasa da günümüzde halen etkin bir kullanımı olduğunu söyleyebiliriz. Özellikle Asp.net ile geliştirilmiş yabancı menşeili yazılımların yerlileştirilmesi çalışmalarında birçok teknoloji firması Asp.net kullanmaya devam etmektedir. Güvenlik önlemi yalnızca uygulama taraflı bir çalışma olmayıp sunucu tarafında da güvenlik ile ilgili yapılacak işlemler illaki bulunmaktadır. Özellikle yeni başlayan asp.net geliştiricileri için bu makalede yer alacak önlemler ve tarifler yeterli olacaktır.
Güvenlik Açığı Nedir?
Bir açıktan bahsedebilmek için öncelikle geliştirdiğimiz yazılım üzerinde güvenlik sorunu teşkil etmeyen yani kapalı yerler olduğundan emin olmalıyız. Açık kapatmak için yapılmış bir çalışma yok ise bir açıktan bahsedemeyiz zaten yazılım yalın bir şekilde saldırıya açıktır. Buradan hareketle diyebiliriz ki bir açığın olabilmesi için birtakım açık kapatma işlemi gerçekleştirilmiş olmalıdır fakat bu işlem sırasında unutulan, ön görülemeyen veya bilinmeyen bir açık bırakılmış olabilir. Güvenlik açığı böyle bir senaryoda meydana gelecek ve sistemi istismar edebilecek kimseler için giriş kapısı niteliği taşıyacaktır.
Asp.Net Web Form Uygulamalarını Daha Güvenli Hale Getirebilmek
Yukarıdaki açıklamadan da hareketle güvenlik kelimesini tam anlamıyla hiçbir zaman kullanamayız çünkü her zaman bir güvensizlik söz konusu olacaktır. Ama uygulamalarımızı makalemizde anlatacağımız bir takım yöntem ile daha güvenli hale getirebiliriz. Şimdi bu önlemleri inceleyelim.
Debug Kapatmak
Geliştirme esnasında açık olan Debug proje yayınlanırken kapatılmalıdır. Proje yayın edilirken (Publish) ayarlanmaz ise Debug açık olarak yayınlanacaktır böyle bir durumda Web.config dosyasından yapılacak bir müdahale ile <system.web> etiketleri arasında resim-2’den de görüleceği gibi Debug kapatılmalıdır.
Resim-2
Hata Mesajlarını Gizlemek
Kullanıcılarımıza yazılımda bir hata meydana geldiğinde hata ile ilgili teknik açıklamaların yazdığı bir sayfa göstermek hoş karşılanmamaktadır. Bunun yerine destek sayfası benzeri bir sayfa göstermek hatayı alan kullanıcı için daha tercih edilir bir görüntü oluşturacaktır. Ayrıca kötü niyetli kişiler hata mesajı içerisindeki teknik bilgiler üzerinden bir bulgu edebilme ve sisteme zarar verme ihtimalleri de düşünüldüğünde hata durumunda kullanıcıyı başka bir sayfaya yönlendirmek mantıklı olacaktır. Yönlendirme işlemi yine Web.config dosyasından resim-3’de gösterildiği gibi yapılmaktadır.
Resim-3
Trace Kapatmak
Projemizde arka planda olanı biteni kimsenin görmesini istemeyiz. Uygulamada meydana gelen hata ve diğer işlemlerin uzaktan takip edilebilmesini sağlayan Trace özelliğinin de Web.config dosyasından kapatılması gerekmektedir. İhtiyaç olması halinde belirli bir süre için tekrar açılabilir. Trace özelliğinin kapatılması işlemi resim-4’te gösterildiği gibi yapılmaktadır.
Resim-4
Http Runtime
Http Runtime içerisindeki öznitelikler ile birçok ayar yapılabilmektedir. Buradaki işlemleri Web.config dosyası üzerinden gerçekleştirmek istemezsek IIS üzerinden menüler vasıtasıyla da gerçekleştirebiliriz.
maxRequestLength=4096 özelliği kullanıcılardan post yöntemi ile gelen verileri KB olarak sınırlar. Özellikle FileUpload nesnelerinin çalıştığı uygulamalarda bu özelliğin kullanılmasında fayda vardır. 4096 varsayılan değer olarak çalışmaktadır.
EnableHeaderChecking=true özelliği Asp.Net Request Header’larını süzer ve zararlı bir request algıladığında hata döndürür.
EnableVersionHeader=false özelliği Asp.Net versiyon bilgisini gizlemektedir.
MaxUrlLength=260 özelliği varsayılan olarak 260 karakter ile gelir ve adres satırındaki karakterlerin uzunluğunu belirler. Gereksiz kullanımda bu sayı daha da düşürülebilir.
ExecutionTimeOut=110 özelliği Asp.Net’in bir istekte hataya düşmeden kaç saniye beklemesi gerektiğini ayarlar. Varsayılan değeri 110 saniyedir. Http Runtime özelliklerinin Web.config ile ne şekilde yapıldığı resim-5’te gösterilmiştir.
Resim-5
Http Header Engellemek
Bir saldırganın saldıracağı platform hakkında bilgi sahibi olmasını gizlemek en doğal hakkımızdır. Sunucumuz ve uygulamamızın versiyonu gibi bilgileri http Header ile gizleriz. Daha doğrusu bu bilgileri öğrenmek için talep gönderen istekleri engelleriz. Bu işlemi Web.config ile gerçekleştirirken diğerlerinden farklı olarak <system.web> etiketi kapsam alanı içerisinde değil <configuration> etiketi kapsam alanı içerisinde resim-6’da olduğu gibi gerçekleştirebiliriz.
“X-Powered-By” özelliği Asp.Net gibi bir sonuç döndürecek olan teknoloji bilgisini gizli tutmayı sağlar.
“Server” özelliği IIS 8.0 gibi bir sonuç döndürecek olan sunucu bilgisini gizli tutmayı sağlar.
“X-AspNet-Version” özelliği Asp.net versiyon bilgisini gizli tutmayı sağlar.
“X-FRAME-OPTIONS value=DENY” özelliği ise Clickjacking almamak için gelecek iframe’leri reddeder.
Resim-6
Zararlı Http İstek Türlerini Engellemek
Http istek metotlarının da düzeltilmesi gerekebilir. Asp.Net genellikle POST ve GET komutlarını kullandığı için bu metotları kabul edip bunun dışında kalanları zafiyet vermemek adına engelleyebiliriz. Bu işlem potansiyel risklerden kaçınmamızı sağlayacaktır. Resim-7’de GET ve POST türündeki isteklerin kabul ediği bunun dışında kalan MOVE, TRACERT, DELETE vb. isteklerin engellendiğini yorumlayabiliriz.
Resim-7
Kullanılmayan Dosya Uzantılarının (MIME-Type) Engellenmesi
Uygulamada yaygın uzantıların dışındaki uzantılar kullanılmıyorsa bu uzantıları boşu boşuna desteklemenin de bir anlamı yoktur. Bu yüzden .jpg, .jpeg, .html, js, .css gibi uzantılara izin verip diğer uzantıları engellemek mümkündür.
Resim-8
Zararlı Karakter Girilmesini Engellemek
XSS olarak da bilinen web sitesine zararlı karakterler gönderme ön savı ile yapılabilen bir saldırı türünden korunmak için Web.config üzerinde resim-9’da gösterildiği gibi önlem alınabilir.
Resim-9
Asp.net sayfalarında örneğin Datalist veya Repater ile veri gösterimi yapılan yerlerde zararlı karakterlerden korunmak için resim-10’da gösterildiği gibi kodların güncellenmesi gerekmektedir.
Resim-10
Resim-10’da yapılan işlemin Code Behind tarafındaki karşılığı ise ad soyad ve öğrenci numarasının kullanıcıdan istendiği bir senaryoda resim-11’de gösterilmiştir.
Resim-11
Önemli İçeriklerin Filtrelenmesi
Uygulama içerisindeki kritik dizin veya dosyalarımızı gizlememiz gerekebilir. IIS hali hazırda App_Data dizinini veya üzerinde çalıştığımız Web.config dosyasını gizlemektedir ancak bunlara ilaveten projede kullandığımız farklı dosya veya dizinleri de resim-12’de gösterilen yöntem ile gizleyebiliriz.
Resim-12
Zararlı URL Dizin Oparetörleri
Uygulama içerisindeki dizinlerde dolaşmayı sağlayan “/”, “\”, “..” gibi karakterlerin proje için önem arz eden dizinlerde (app_data) işlem yapamaması için bir filtre kurgulamak mümkündür. Yetkisi bulunmayan kullanıcının URL vasıtasıyla dizinlere erişimini engellemek için resim-13’teki yöntem uygulanmalıdır.
Resim-13
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: asp.net, IIS güvenlik, asp web form güvenlik, asp.net güvenlik, IIS secure, asp.net security, web forms security, asp.net web uygulama güvenliği, IIS ve asp.net güvenliği, asp.net xss, clicjacking asp.net, http request asp.net web form, asp.net version gizlemek
Teşekkürler