Tehdit Modelleme

.NET ve ASP.NET tarafından sağlanan güvenlik çatısı güçlü olsa da bazı temel prensipleri akılda tutmak ve bu özellikleri doğru bir şekilde ve doğru zamanda kullanmak gereklidir. Bunun için güvenlik öğelerini, uygulama geliştirmenin ilk aşamasından itibaren kullanmak gereklidir.

Güvenli (secure) mimariler dizayn etmek için uygulama ortamının çok iyi bilinmesi gerekir. Mesela uygulamamıza kimler erişecek ve muhtemel kötü niyetli ataklar nereden gelebilir vb. Dolayısıyla güvenli uygulama mimarileri ve dizaynları geliştirmede en önemli faktör, çevresel öğeleri çok iyi anlamaktır. Bunlar kullanıcılar, uygulamadaki giriş noktaları ve muhtemel atak noktalarıdır.

Bu yüzden Tehdit modelleme, günümüz yazılım mimarisinde önemli bir yer teşkil etmektedir. Tehdit modelleme (Threat modelling) muhtemel tehditler, bu tehditleri önem sırasına koyma ve sonra bu tehditleri temel alan hafifletme tekniklerine (mitigation techniques) karar verme üzerine uygulamamızın öğelerini analiz etmenin yapısal bir yoludur. Tehdit modelleme başka bir yönden de önem arz etmektedir. Bildiğimiz gibi bütün potansiyel tehditler, authentication ve authorization gibi güvenlik teknolojileri ile hafifletilemiyor. Bir başka deyişle bazı tehditler teknik yollarla çözüme kavuşturulamıyor. Mesela bir bankanın online şubesi, web sitesi üzerindeki trafiği güvenlik altına almak için SSL kullanıyor (Secure Socket Layer). Fakat kullanıcı, sayfanın bankanın gerçek sayfası olduğunu, bir hacker"ın sahte sitesi olmadığını nasıl anlayacak? Bunun tek bir yolu var: SSL kanalını kurmak için kullanılan sertifikaya bakmak. Ancak her kullanıcının bunun farkında olması düşük bir ihtimaldir; dolayısıyla kullanıcıları bilgilendirmeliyiz. Bu senaryodakine benzer hafifletme teknikleri, birer güvenlik teknolojisi değillerdir. Bu, bütün kayıtlı (registered) kullanıcıların sertifikaya nasıl bakmaları gerektiğini bildiklerinden emin olmayı gerektirir (Tabi ki onları bunun için zorlayamayız; fakat bilgileri doğru şekilde dizayn edersek bir çoğuna bunu yaptırabiliriz). Tehdit modelleme, sadece teknik konuları değil bu gibi durumları belirlemeye yardım eden bir analiz metodudur.

Güvenli kod yazmanın temel prensipleri

Kullanıcıların kontroller vasıtasıyla yaptıkları girişlere asla güvenilmemelidir... Tersi ispatlanana kadar bütün kullanıcılar birer şeytandır prensibini de unutmamak gerekir. Dolayısıyla girişler, çok kuvvetli bir şekilde doğrulanmalıdır (validation). En doğru olan, sadece girilmesi gereken değerlere izin vermektir.

SQL ifadeleri yazarken asla string birleştirme kullanılmamalıdır... Sql"den iğne yemek istemiyorsanız (sql injection) her zaman parametrelendirilmiş sorgular kullanılmalısınız. Aynı zamanda sql cümlelerin olduğu yerlerde try-catch bloğu sonucu kullanıcıya verilecek hata mesajında kendi özel mesajımızı kullanmak daha güvenlidir; çünkü Exception ya da Exception türevi sınıfların Message özelliği ile kullanıcıya veritabanımız hakkında bilgi gösterilebilir.

Kullanıcıdan alınan bilgiler, doğrulanmadan ve encode edilmeden; yani doğrudan web sayfasında gösterilmemelidir... Kullanıcı bazı HTML parçaları girebilir (mesela bir script). Bu yüzden her zaman HttpUtility.HtmlEncode() kullanarak < ve > gibi karakterlerden kaçmakda fayda vardır. Alternatif olarak bu geçerlilik kontrolünü yapacak bir web kontrolü kullanılabilir.

Sayfanın gizli alanlarında (hidden field) önemli, değerli, iş bilgisi taşıyan ya da akışı etkileyecek veri saklamamak gerekir. (Gizli alanlar tarayıcıdaki kaynak sayfaya bakılarak kolayca görülebilir, değiştirilebilir, kaydedilebilirler. Ardından da tarayıcı eklentileri (browser plug-in) ile mail gönderir gibi sunucuya gönderilebilirler)

View-state içerisinde önemli, kritik veri saklanmamalıdır (Çünkü view-state, bir gizli alandır. Kolayca decode edilebilir. Bu arada eğer sayfada @Page etiketinde EnableViewStateMac = true yapılırsa view-state şifrelenir).

Cookie"ler korunmalıdır... Forms authentication kullanılırken cookie"ler olabildiğince geç oluşturulup ihtiyaç kalmadığında silinmesi için timeout süresine sahip olmalıdır.

SSL kullanılmalıdır... Eğer web sitemiz, genel olarak hassas veriler içeriyorsa bütün siteyi SSL kullanarak koruma altına almak gerekir. Ayrıca direk SSL tarafından korunamayan resim ve diğer dosyaları da korumayı unutmamak lazım.

ASP.NET GateKeeper"ları ve Sorumlulukları

Uygulamamızın güvenliğini artırmanın güzel bir yolu, yerinde birçok bileşenle güvenliği sağlamaktır. Gatekeepers (takipçiler, koruyucular), güvenlik altyapısına bir yol bir boru hattı modeli yerleştiren kavramsal bir oluşumdur. Bu model, güvenliği artırmamıza yardımcı olur. Gatekeeper modeli şunu savunur ki; uygulamaya gerektiğinden fazla güvenlik mekanizmaları koymak gerekir. Bu mekanizmalardan her birine güvenlikle ilişkili bazı koşullara zorlamaktan sorumlu gatekeeper adı verilir.Eğer gatekeeperlardan biri başarısız olursa, hacker kaynaklara giden yoldaki diğer gatekeeper"la karşılaşacaktır. Ne kadar çok gatekeeper varsa, hacker"ın hayatı o kadar zorlaşır. Bu model, güvenli uygulamalar geliştirmek için zorunlu prensipleri desteklemektedir: Olabildiğince güvenli ol, hacker"ların hayatını olabildiğince zorlaştır. Yolun sonunda kaynaklara ulaşmak için gereken gatekeeperlar aşıldığında belki sadece sayfamızın kodları vardır, ancak yine de bu güvenlik prensipleri uygulanmalıdır. Bu şekilde merkezi bir güvenlik bileşeni uygulamak iyi bir fikir olabilir. Aynı şeklide iş katmanı da güvenli hale getirilebilir. ASP.NET uygulama altyapısı, bunu güzel bir şekilde uygulamaktadır.
Bir web sitesinde güvenliği uygulamanın yolları genelde aynıdır (Ayrıca tehdit modellemede bizim belirleyeceğimiz seviyeler bunlara eklenebilir).

Authentication : Öncelikle kullanıcıların kimliklerini doğrulamak gereklidir. Authentication şu soruyu sorar: Uygulamayı kullanan kim?

Authorization : Uygulamamızla çalışanın kim olduğunu öğrendikten sonra o kullanıcının hangi operasyonları gerçekleştirebileceğini ve hangi kaynaklara erişebileceğine karar vermek gereklidir. Yani authorization şu soruyu sorar; Senin geçiş iznin ne?

Güvenilirlik : Kullanıcı uygulama üzerinde çalışırken kimsenin kullanıcı tarafından işlenen hassas verileri görmediğinden emin olmak gerekir. Bu yüzden kullanıcı tarayıcısı ile web sunucumuz arasındaki kanalı şifrelemek gerekir (SSL). Dahası, arka plandaki verileri de şifrelemek gerekir. Mesela kullanıcı makinesine atılan cookieleri... Aynı zamanda veritabanı yöneticisi ve uygulamanın yayınlandığı (host edildiği) şirketin çalışanlarının da görmemesi için verileri şifrelemek gereklidir.

Tutarlılık : Tarayıcı ve sunucu arasında gidip gelen verinin illegal aktörler tarafından değiştirilmediğinden emin olmak gerekir. Bu tarz tehditleri hafifletmenin bir yolu dijital imza kullanmaktır.

ASP.NET, authentication ve authorization için bize basit bir altyapı sunar. Ayrıca .NET Framework ile gelen temel sınıf kütüphanesinde, System.Security isim alanı altında veriyi şifreleme ve imzalama için bazı sınıflar bulunmaktadır.

Authentiction

ASP.NET"de 4 tür kimlik doğrulama sistemi mevcuttur. Bunlar :

1) Windows authentication
2) Forms authentication
3) Passport authentication
4) Custom authentication

Mesela windows işletim sistemi, login olan her kullanici için 96-bit bir numara kullanır, buna SID (Security identifier) denir. Bütün authentication çeşitleri, sunucuya talepte bulunan kişinin kim olduğunu bilmemizi sağlar ki bundan kişiselleştirme için faydalanılabilir. Çünkü kimlik (identity) bilgisini web sayfasında kişiye özel karşılama mesajı göstermek için veya sayfanın görünüşünü değiştirmek için kullanabiliriz. Yine de kullanıcının uygulama içerisinde yapacaklarını kısıtlamak için authentication yeterli değildir. Bunun için authorization gereklidir.

Güvenilirlik ve Uyumluluk için Şifreleme

Güvenilirlik (Confidentiality), verinin ağ (network) üzerinde sunucu ve istemci tarayıcısı arasında gidip gelirken ya da bir veri kaynağına kaydedilirken başka kullanıcılar tarafından görülmemesidir.
Uyumluluk (Integrity) ise, yine ağ (network) üzerindeki ya da veri kaynağına kaydedilen verinin başka kullanıcılar tarafından değiştirilmediğinden emin olunmasıdır. Her ikisi de şifreleme (encryption) tabanlıdır. Şifreleme, veriyi karıştırmak, dolayısıyla bir kullanıcı tarafından okunmasını engellemek demektir. ASP.NET"de şifreleme, authentiction ve authorization"dan tamamen farklı bir özelliktir. Şifrelemeyi tek başına da, diğer özelliklerle bir arada da kullanabiliriz. Bir web uygulamasında şirelemeyi iki sebebten dolayı kullanmak isteyebiliriz:

1. Ağ üzerindeki verinin iletişimini korumak için: Mesela internet ortamında bir e-ticaret sitesinden alış-veriş yaparken bu ortamda bulunabilecek bir dinleyicinin (eavesdropper) kredi kartı no"mu okuyamadığından emin olmak isteyebilirim. Endüstriyel standartların yaklaşımına göre bunun çözümü SSL (Secure socket layer)"dir. SSL aynı zamanda tutarlılığı sağlamak adına dijital imza da sağlamaktadır. SSL, ASP.NET tarafından sağlanmaz, bu IIS"e entegre edilebilecek bir özellikir.

2. Veritabanı ya da bir dosyadaki kalıcı bilgileri korumak için:  Mesela gelecekte kulanmak üzere  kullanıcının kredi kartı no"sunu veritabanına kaydetmek istiyoruz. Bunu açık metin (plain text) olarak kaydedebilmemize rağmen, çok da iyi bir fikir değildir. Bunun yerine veritabanına kaydetmeden önce .NET framework tarafından bize sağlanan tipler yardımıyla veri şifrelenebilir.

Şu ana kadar anlatılanları bir araya getirirsek :

Kullanıcı bir siteye girdiğinde isimsiz bir kullanıcıdır (anonymous user). Yani uygulamamız gelenin kim olduğunu bilmez ve bu onu ilgilendirmez. Onu doğrulamadığımız (authenticate etmediğimiz) sürece de öyle kalacaktır. Varsayılan olarak isimsiz kullanıcılar bütün ASP.NET web sayfalarına erişebilirler. Fakat isimsiz erişimi olmayan bir siteye girildiği zaman şu aşamalar gerçekleşir:

1) Talep web sunucusuna gönderilir. Bu aşamada kullanıcının kimliği (identity) bilinmediği için ona login olması söylenir. (Bunun için özel bir web sayfası hazırlanabilir) Login sürecindeki ayrıntılar, authentication türüne bağlı olarak değişir.

2) Kullanıcı güvenlik bilgilerini verir ve ardından eğer form authentication kullanılıyorsa uygulamamız tarafından, windows authentication kullanılıyorsa IIS tarafından kontrol edilir.

3) Eğer bilgiler doğruysa kullanıcı talep ettiği sayfaya yönlendirilir. Verilen bilgiler doğru değilse kullanıcı yeniden log-in sayfasına yada Erişim reddedildi mesajı içeren bir web sayfasına yönlendirilir.

Kullanıcı sadece belli kullanıcılara ya da belli role sahip kullanıcılara açık bir web sayfası talep ederse yukarıda anlatılan aynı süreçten geçer fakat bu sefer fazladan bir adım vardır. Kullanıcı eğer bilgilerini doğru girmişse, talep ettiği sayfaya giriş hakkı olup olmadığı da kontrol edilir. Bu da sürecin authorization kısmıdır. Eğer kullanıcının talep ettiği kaynağa hakkı yoksa Erişim reddedildi mesajı içeren bir web sayfasına yönlendirilir.