ASP.NET Güvenliği ve Platform Tasarımı
Öncelikle genel yapılan geyiklerden birini kestirip atalım:
Tüm sunucu-taraflı (server-side) diller aynı seviyede güvenlidir, herşey kodu yazan kişiye bağlıdır.
Bunu unutun, yok böyle bir şey. Hemen açıkça söyleyelim mesela ASP.NET tasarımı PHP ye göre çok daha güvenlidir. Şimdi bir çok kişi yorumlara saldırmadan önce yazıya devam edelim. Mesela Struts (dil değil platform/framework) hatırı sayılır derecede bir çok platformdan daha güvenlidir.
Her dilde ve platformda güvenli olmayan yazılım geliştirebilirsiniz ama bazı platformlarda güvenli olmayan yazılım geliştirmek çok daha kolay. Şimdi bir dilin - platformun güvenlik noktasında nasıl analiz edilebileceğine bir bakalım.
Server-Side dillerin Güvenlik Analiz Kriterleri:
Yazılım güvenliği, platformun kendisinde çıkan açıklar (buffer overflow, yanlış çalışan encoding fonksiyonları vs.)
Platform tarafından sunulan güvenlik kütüphaneleri, fonksiyonlar
Platformun dokümantasyon ve eğitimlerin güvenli yazılım geliştirme pratiklerini teşvik ediyor olması. Güvenli kod yazmanın kolay olması
Güvenli varsayılan ayarlar ve fonksiyonlar varsayılan olarak güvenli şekilde çalışması
Burada bütün platformaları karşılaştırmayacağım zaten farklı platformlardaki teknik yetersizliğimden dolay bunu yapma imkanım da yok ama örnekler verip ASP.NET' in neleri başarılı bir şekilde yaptığını göstermeye çalışacağım.
Platformun Kendisinde Çıkan Açıklar
Bu tip açıklara şu örnekleri verebiliriz : ASP.NET Request Validation Bypass, PHP Global Overwrite, PHP Zend Hash Problemleri, Struts Validation Bypass vs.
PHP bu konuda tamamen sabıkalı, The Month of PHP Bugs bunu bize gösterdi zaten. Burada söyleyecek pek bir şey yok, ASP.NET in .NET Framework' ü üzerinde geliştirilmiş olması aynı Java gibi onu Buffer Overflow ve benzeri ataklardan tamamen korunmasına neden oluyor. Dolayısıyla .NET Framework' ün temelinde bir sorun çıkmadıktan sonra bir dizi güvenlik açığının ASP.NET te görülmesi imkansız hale geliyor.
Bunun harici foksiyonların kendilerinde çok ciddi sorunlar çıkmadı buna rağmen NULL karakterler ile string birleştirme operastyonları etkileme gibi açıkları çıktı. Dolayısıyla ASP.NET' te bu konuda mükemmel değil ama çok da kötü değil.
Güvenlik Kütüphaneleri ve Fonksiyonlar
ASP.NET tasarlandığı gibi kullanıldığında şu sorunların hepsini çözüyor :
Parameterised Query kullanımı
Default olarak control' lerde encoding desteği, Request Validation desteği (bu sadece derinlemesine defans faktörü, sorunun çözümü değil). Bunlara rağmen ASP.NET' in control encoding desteğinin o kadar mükemmel olmadığını da belirtmek lazım.
Güvenli Kullanıcı Sistemi (Login/Logout, Role sistemi, şifre güvenliği vs.)
ASP.NET Membership sistemi basit ve güvenli şekilde bir kullanıcı sistemi oluşturmanıza izin veriyor.
ViewStateUserKey ile uygulama CSRF ataklarına karşı güvenli hale getirilebilir.
İç fonksiyonların güvenli olması otomatik olarak CRLF açıklarından (HTTP Splitting) koruyor. Bazı fonksiyonlarda sorun olsa da en azından genelde güvenli diyebiliriz.
ASP.NET istemci tarafına giden datanın modifiye edilmeden döndüğünü kontrol edebiliyor ama bu aslında pek iyi bir yazılım geliştirme pratiği değil. Eğer istemci tarafına giden datanın aynı olmasını istiyorsanız istemciden gelen parametreyi kullanmaz ve datayı session yada benzeri bir yerde tutarsınız. Buna rağmen bazı yazılımlar scability amaçlı buna ihtiyaç duyabiliyorlar.
Ek olarak ASP.NET Validators var, bunlar sayesinde girdi denetimi yapmakta gayet pratik.
Bunun harici güvenlik ile ilgili bir çok hazır fonksiyon ve kütühane sunuyor:
Şifreleme ve Encoding Kütüphaneleri. Ek olarak bu kütüphaneler UTF8 ve UTF8 olmayan data ile de iyi geçiniyorlar.
Güvenli Yazılım Geliştirmeye Teşvik Etme
ASP.NET' in resmi dokümantasyonu güvenliğe çok önem veriyor. Bir çok güvenlik ile ilgili makale ve bu güvenlik özelliklerinin nasıl kullanılacağına dair dokümantasyon sunuyor. Bundan daha da önemlisi örneklerde Parameterised Query kullanımı gibi güvenli kullanımlar öneriliyor ve gösteriliyor. Bir çok işlem için gerekli fonksiyonlar zaten olduğundan kullanıcıların kendi kodlarını yazması gerekmiyor.
Güvenli Varsayılan Ayarlar ve Fonksiyonlar
Bu en önemli özelliklerden biri ve Microsoft' un güvenlik devriminden beri çok önemverdiği bir unsur. ASP.NET varsayılan olarak hata mesajlarını göstermiyor, debugging' i aktif hale getirmiyor.
Response.Redirect fonksiyonu da varsayılan olarak güvenli fonksiyonlara güzel bir örnek olabilir. Mesela PHP' de sayfa yönlendirme işleminden sonra manuel olarak sayfanın işlemin durdurmanız gerekiyor*. Bunu yapmdığınızda üyelik gerektiren sayfalara şifresiz erişim mümkün olabilir. ASP.NET ise bu fonksiyon varsayılan olarak işlemi durduruyor ama isterseniz ekstra bir parametre ile çağırıp sayafnın işlemesini durdurabiliyorsunuz.
Bu yazı bir karşılaştırma yazısı değil daha çok güvenli platform geliştirmeye güzel bir örnek olarak ASP.NET' i gösterme amaçlıdır. Şu an hangi penetration tester' a sorarsanız sorun ASP.NET sitelerinin genellemede çok daha güvenli olduğunu söyleyecektir**.
Güvenli Kod Yazmak Bunun Neresinde ?
Eğer kod güvensiz yazıldıysa maalesef sizi koruyabilecek bir platform henüz keşfedilmedi, ek olarak mantıksal açıklar da aynı şekilde. Hiç bir yazılım dili ya da platform sizi böyle delice bir şey yapmaktan alı koyamaz!
* Bunun ana nedeni bu fonksiyonun (header) çok jenerik olması.
** En azından 50 site üzerinde penetration testing yapıp, değişik platformlarda değişk siteler ile çalıştığını varsayıyorum.
*** Nihayet uzun bir aradan sonra teorik ama hala teknik bir yazı yazabildim.