Kişisel güvenlik sitemde yayınladığım bir makaleyi burada sizlerlede paylaşmak istedim. Umarım birileri okur ve uygular. Umarım ileride Türkiyede daha güvenli web siteleri olur. Merhaba arkadaşlar bu makalede elimden geldiğince ASP. NET web form ile geliştirdiğimiz web sitemizi nasıl daha güvenli hale getirebileceğimizi anlatmaya çalışacağım. Dikkat ederseneniz daha güvenli hale getirmek dedim çünkü hiçbir zaman tam güvenlik yoktur. Fakat bu makalede anlatılanları yaparsanız en azından script kiddieleri sitenizden uzak tutabileceğinizi belirtmek istiyorum. Sql Injection Öncelikle Sql injection saldırısından bahsetmek istiyorum. Sqli saldırısı, kullanıcıdan bir girdi alıp bu verileri herhangi bir filtrelemeden geçirmeden sql kodlarınızda kullanmanızdan kaynaklanır. Fazla detay vermeden direk korunma yöntemlerine geçiyorum. string Gelen; Gelen = TextBox1. Text. Replace ; Gelen = Gelen. Replace ; Gelen = Gelen. Replace ; SqlCommand sorgu = new SqlCommand ; sorgu. Parameters. Add ; Kodlarınızı bazı karakter filtrelemelerinden geçirerek ve direk SQL koduna değilde parametre şeklinde göndererek bu zafiyetten korunabilirsiniz. İsterseniz Stored Procedure kullanarakda bu açıklıktan kurtulabilirsiniz. XSS Zafiyeti Bu zafiyet sitenize javascript kodlarının gömülmesidir. Bildiğiniz üzere Javascript kodları ilede bir çok şey yapılabiliyor. Bu önemli zafiyetten kurtulmak için temel prensibimiz olan "Kullanıcıdan gelen veriye güvenme!" mantığını uyguluyoruz ve kullanıcıdan veri aldığımız kısımlarda gelen değerleri filtrelerden geçiriyoruz. Web. config dosyamıza şunları ekliyoruz. < system. web> < pages buffer="true" validateRequest="true" /> < /system. web> Bu web. config ayarı sizi tehlikeli HTML karakterlerinden koruyacaktır. Bu kodda girilen verileri kontrol ettik fakat her zaman output karakterleride kontrol edilmelidir. Onun için ise aşağıdaki kodu yazıyoruz. <%#HttpUtility. HtmlEncode(Eval . ToString %> Böylelikle artık veritabanından geri gelen verileriniz web sayfanızda yayınlanırken güvenli olacaklardır. Parola Güvenliği Parola güvenliğinin amacı veritabanınız o ya da bu şekilde çalındığı zaman kullanıcıların parola değerlerini kötü niyetli kişiye göstermemektir. Çünkü kullanıcılar sitenizde kullandığı parolalarını başka sitelerdede kullanıyor olabilir ya da web sitenize login olarak o kişinin profilini mahvedebilir. Biz kötü niyetli kişinin veritabanını ele geçirse bile kullanıcıların parolalarını bilememesini istiyoruz. Öncelikle hemen belirtmeliyim. Yeterli zaman ve performans gücü varsa bu parolalar o ya da bu şekilde elegeçirilecektir. Biz bu işlemin süresini yıllar seviyesine çıkararak kötü niyetli kişinin yılmasını amaçlıyoruz. Bunun için ASP. NET in yanında getirdiği MD5 ve SHA1 algoritmaları olsada bu algoritmalar zayıf olduğundan bunların kullanılmasını önermiyoruz. Kendi algoritmanızı yazabilir ya da daha güvenli olan SHA512 vb algoritmaları kullanabilirsiniz. Fakat biz burada şifrenin bir kere kriptolanmasınıda önermiyoruz. En az 2 kere farklı algoritmalarla kriptolamalısınız. Böylelikle bir plain-text i kırsa dahi karşısına başka bir plain-text çıkacaktır. Bu durumda yılması daha olası ve kırılması daha uzun sürecektir. Fakat buda bize yeterince güvenli gelmediğinden tuzlama dediğimiz işlemide uygulamalıyız. Tuzlama işlemi güvenli parolalar oluşturmayan kullanıcılara zorla güvenli parola oluşturmaktan geçer. Bu ne demek derseniz öncelikle neden basit parola kullanılmaması gerektiğini anlatmalıyım. Basit parolalar Rainbow tabloları dediğimiz tablolarda bulunurlar. Bunlar daha öncede oluşturulmuş plain text-clear text mantığında oluşturulmuş tablolardır. Yani test kelimesinin SHA1 ile şifrelendiğinde ki karşılığının a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 olduğunu tutan tablolar demektir. Kötü niyetli kişi veritabanını ele geçirdiğinde bu SHA1 kodunu gördüğünde basit bir "SHA1 decrypter" Google sorgusu ile bulabileceği ilk sitede SHA1 kodunu yazar ve karşısına test yazısı çıkar. Kullanıcılar ne kadar basit parolalar kullanırsa kullansınlar bunları güvenli hale getirmeliyiz. Bu yüzden kullanıcının diğer bilgilerinden bir salt yaratmalıyız ve bunu kişinin parolasına ekleyip kriptolama algoritmalarına göndermeliyiz. Burada dikkat edilmesi gereken husus her kullanıcının salt ı farklı olmalıdır. Ayrıca parolanın minumum karakter uzunluğu ve komplike olma durumlarıda oldukça önemlidir. Çünkü sadece sayılardan oluşan bir parolayı kırmak Brute Force saldırısı ile kolayken içinde hem sayı hem büyük küçük karakter hemde!#+^vb karakterlerin olduğu bir parolayı kırmak kolay değildir. Özet geçmek gerekirse; SHA512(RSA((komplike(min8 +salt)) LFI/RFI Korunma Bu zafiyet sitemizde kullanıcıdan bir dosya alırken o dosyanın formatını kontrol etmeden sunucumuza yüklenmesini kabul etmemizden kaynaklanır. Shell adını verdiğimiz zararlı dosyaları sunucumuza yükleyip daha sonra o dosyanın bulunması ile bu açıklık sömürülür. Shell dediğimiz dosyalar sunucunuzdaki bütün dosyaları görme, silme, düzenleme ve yeni dosya ekleme gibi özellikler sağlarlar. Göründüğü üzere bu zafiyet belkide en büyük açıklıklardan birisidir. Bunun için dosya yüklediğimiz alanlarda validation ile kabul ettiğimiz dosya tiplerini belirtmeliyiz. < asp:RegularExpressionValidator ID="RegularExpressionValidator1" runat="server" ErrorMessage="Dosya formatı uygun değil. " ValidationExpression="^.+\. | | $" ValidationGroup="g1" ControlToValidate="FileUpload1">< /asp:RegularExpressionValidator> Fakat validation tek başına güvenliği sağlamaz. Validation ile beraber. cs kısmındada dosyanın formatını kontrol etmeliyiz. Validationların belli teknikler ile atlatılabildikleri görülmüştür. Hatalarınızı yüzlerine vurmayın! Kodlamamızdan ya da kullanıcının yanlış/kötü niyetli parametreler girmesinden dolayı oluşabilecek hata sayfalarımızda mümkün olan en az bilgiyi göstermeli ve hatta başka bir sayfaya göndermeliyiz. Çünkü kötü niyetli kişi için ulaşabileceği en küçük ayrıntı değerlidir. < system. web> < customErrors mode="RemoteOnly" defaultRedirect="siteniz.com"> < error statusCode="404" redirect="404.aspx"/> Bu kodda görüldüğü gibi 404 hatası dışında bir hata oluştuğunda anasayfamıza 404 hatası oluştuğunda ise 404.aspx sayfasına kullanıcılarımızı yönlendirecektir. Kim olduğunuzu bilmesinler Eğer sadece domain satın alıp daha sonra başkasına satma planınız yok ise whois. sc adresindeki domain bilgilerinizi domain hizmetini aldığınız şirketten gizlemesini isteyin. HTTP istek türleri Genellikle web siteleri GET ve POST HTTP isteklerini kullanırlar bunun dışındaki bütün istekleri engelleyebilirsiniz. Engellemek için aşağıdaki kodları yazabilirsiniz. < requestFiltering> < verbs allowUnlisted="false"> < add verb="GET" allowed="true"/> < add verb="POST" allowed="true"/> < /verbs> < /requestFiltering> < /security> Web Config Dosyanızı kontrol edin Malum ASP. NET projelerimizin en kritik bilgilerini tuttuğumuz yerlerden biri şüphesiz web. config dosyalarıdır. Web. config dosyalarımızın güvenliğini kontrol etmek için bir araç bulunmakta. Bu araç ile web. config dosyanızı daha güvenli hale getirebilirsiniz. Bunun içinhttps://www.code.google.com/p/wcsa/ adresinden web. config security analyzer dosyasını indirip web. config dosyanızı localde kontrol edebilir ve gerekli önlemleri alabilirsiniz. Yedeklemeyi unutmayın! Web sitenizin kaynak kodlarını ve veritabanınızın yedek dosyalarını farklı bir yerde saklamayı unutmayın. Olaki bir saldırıya maaruz kaldığınızda elinizde geri yüklemek için güncel dosyalar bulunsun. Veritabanınızı yedekleme yetkisi sizde bulunmuyorsa teknik destek ile iletişime geçin ve veritabanınızın yedeğini isteyin. Log dosyalarınızı takip edin Her zaman sitenizde görünür değişiklikler olmasına gerek yok. Kötü niyetli kişi sisteminize sızmayı deniyor olabilir ya da çoktan sızmış ama zarar verici bir eylemde bulunmamış olabilir. Siz her ihtimale karşı düzenli olarak log dosyalarınızı kontrol edin. Kullanıcı Girişleri Kullanıcı doğru bilgilerle sisteme giriş yaptığında IP adresini ve sunucu saatini tutun. Bunu her doğru girişte yapmalısınız. Kötü niyetli kişi başka bir yerden kullanıcının şifrelerini çalmış olabilir ve sisteme oymuş gibi girip uygunsuz yorumlar vb. şeyler yapabilir. Gerçek kişi hesabını çalan kişiye dava açmak istediğinde savcılığa vereceğiniz bilgiler olmalı. Burada sunucunun saatini almalısınız. İstemci taraftaki saat değiştirilmiş olabilir. Bu tedbir tabiki VPN kullanan bir hacker için bir anlam ifade etmeyecektir fakat savcılığa vermek için elinizde en azından yeterli bilgilerin bulunması şart. CAPTCHA kullanın Bir program tarafından sürekli login sayfanızda bir kullanıcının parolasına brute force saldırısı düzenlenmesini istemiyorsanız captchakullanmalısınız. Burada önemli bir nokta her form sayfasında varsayılan olarak kullanmaktansa bilgiler 3 kere yanlış girildiğinde captcha in çıkması kullanıcıyı rahatsız etmeyecektir. Parola Değiştirme Parola değiştirme, mail adresi değiştirme vb. alanlarda bilgilerin değiştirilebilesi için mutlaka mevcut parolayı sorun. Çünkü kötü niyetli kişi kurbanın sadece cookie bilgilerini çalarak oturum açmış olabilir. Fakat kurbanın parolasını bilmediği için bilgilerini değiştiremeyecektir. Dilerseniz mevcut parolayı sorduğunuzda doğru bilgiler girilmediğinde oturumu kapatabilir ve hesabın e-mail adresine bilgilendirme e-mail i atabilirsiniz. Trace i kapatın Trace web uygulamamız hakkında derince bir bilgi veren sistemdir. Varsayılan olarak zaten kapalı olarak gelmektedir. Kapatmak isterseniz aşağıdaki kodu yazabilirsiniz. < system. web> < trace enabled="false" localOnly="true" /> < /system. web> Sakıncalı Http Headerları engelleyin Http header bilgileri içerisinde oldukça önemli bilgiler taşımaktadır. Tabiki bu gizlediğiniz bilgiler farklı araçlar ile tespit edilebiliyor olsada amacımız hackerın işini zorlaştırmak < system. webServer> < httpProtocol> < customHeaders> < remove name="X-Powered-By" /> // Teknoloji bilgisinin döndürülmesini engeller Örn: ASP. Net < remove name="X-AspNet-Version" /> //ASP. Net versiyon bilgisinin döndürülmesini engeller. < /customHeaders> < /httpProtocol> < /system. webServer> HTTP Runtime Değerleri HTTP runtime değerleri uygulama hakkında birçok ayarı yapabileceğiniz bir alandır. maxRequestLength="4096" özelliği ile sayfaya POST edebileceğiniz en fazla veriyi KB cinsinden sınırlamış olursunuz. enableHeaderChecking="true" özelliği ASP. Net Request Header'larını kontrol ederek zararlı requestlerde hata döndürür. enableVersionHeader="false" özelliği ASP. net versiyon bilgisini gizler. maxUrlLength="260" özelliği adres satırındaki karakterlerin uzunluğunu belirler. Gereksiz ise sayı düşürülmelidir. Varsayılan 260dır. Kimseye güvenmeyin Ve son olarak ASP. NET in sağlamış olduğu Validationlara sakın ama sakın güvenmeyin. Evet kullanın fakat tek başına değil. Validationdan sonra her zaman sunucu tarafında kendi kodlarınız ile kontrol edin. Çünkü Validationlar istemci tarafından post edilirken kontrol ediliyor. Örneğin file upload kısmınız var ve. pdf dışındaki dosyaları almak istemiyorsunuz. Bunun kontrolünü sağlamak için hem validation hemde sunucu taraflı koruma kullanın. string Uzanti = System. IO. Path. GetExtension(FileUpload1. PostedFile. FileName); Kodunu kullanarak yükleyeceğiniz dosyanın uzantısını alabilir daha sonra if ilede bunu kontrol ettirebilirsiniz.

Hocam çok değerli bilgiler, elinize emeğinize sağlık. Ben asp. net'te yeniyim. Basit bir forum tarzında site yapıyorum. Site basit olduğu için veritabanı olarak access kullanmayı düşünüyorum. Access'de veri tabanı güvenliği bakımından neler tavsiye edersiniz?Bunun dışında asp. net uygulamasının sunucu üzerindeki güvenliği için neler yapılabilir?Soru biraz saçma gelebilir, sunucu güvensizse yapacak bir şey yok diyebilirsiniz fakat yinede insan herhangi bir önlem olup olmadığını bilmek istiyor. Örneğin sitemizi sunucuya yükledik. Sunucunun kötü niyetli bir çalışanı.aspx sayfaların kodlarında değişiklik-ekleme yaparak kullanıcı bilgilerini javascript ile çalabilir mi?Yada. cs, veritabanı dosyaları, diğer dosyalar üzerinde oynamalar yapmasını engellemek için biz neler yapabiliriz? Teşekkür ederim, iyi çalışmalar.