Merhabalar,

Öncelikle bu güzel makaleyi bizlerle paylşayan ” Önay Metin Kıvılcım ” teşekkürü borç bilirim, websitesitesinin linki paylaşıcaktım ama kapanmış. ASP.NET web form ile geliştirdiğimiz web sitemizi nasıl daha güvenli hale getirebiliriz. Dikkat ederseniz 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

Sql 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.

string Gelen;
Gelen = TextBox1.Text.Replace(“/”,””);
Gelen = Gelen.Replace(“’”,””);
Gelen = Gelen.Replace(“=”,””);

SqlCommand sorgu = new SqlCommand(“Select * from tablo where Ad=@ad”);
sorgu.Parameters.Add(“@ad”,Gelen);

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(İletişim bölümü,yorum bölümü) 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(“Yorum”))%>

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 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(doğum tarihi,nickname,e-mail vb.) bir salt(tuz) 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(Büyük-küçük karakter,!#% vb karakterler) 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(clear text))+salt))

LFI/RFI Korunma

Bu zafiyet sitemizde kullanıcıdan bir dosya alırken o dosyanın formatını(.exe vb) 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. (Sadece jpeg formatını kabul eder.)” ValidationExpression=”^.+\.((jpg)|(png)|(JPG))$” 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=”http://www.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çin
https://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 adresi 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 captcha kullanmalı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” />
<remove name=”x-aspnet-version” />
<remove name=”x-powered-by-plesk” />
</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.

Publish edin

Web sitenizi web sayfanıza koyarken publish ederek yükleyin. Böylelikle sunucuya sızan birisi kaynak kodlarınıza ulaşamaz hemde sitenizin daha hızlı çalışmasını sağlarsınız.

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.

Ayrıca cookie güvenliği üzerine bu yazımızıda okumanızı tavsiye ederim