Yazılım testleri başarılı yazılım firmalarını diğerlerinden ayıran en önemli faktörlerden biridir. Bu bölümde yazılım testinin neden önemli olduğunu ve test yöntemlerinden bir olan “Fuzzing” tekniğini inceleyeceğiz.
Programcılık ile amatör ya da profesyonel ilgilenen herkes yazılım testi tekniklerinden birkaçını bilir ya da programcılığın getirdiği iç güdülerle farkında olmadan uyguluyor olabilirler. Yazılım testleri birçok alt kategoriye ayrılır. Birim testleri küçük parçaların biraraya gelmeden önce analiz edilmesini sağlar. Sistem ve entegrasyon testleri modüllerin birbirleriyle uyumunu onaylar. Regresyon testleri kod üzerinde yapılan değişikliklerden sonra da her bir parçanın uyum içerisinde çalıştığını kontrol eder. Güvenlik testi tahmin edebileceğiniz gibi verilerin korunduğundan emin olur.
İnternette bulabileceğiniz kaynak kodu tarayıcıları, güvenli derleyiciler ve uygulama tarayıcıları yazılım geliştiricilerinin uygulama üzerindeki açıkları bulmasına yardımcı olur. Bu bölümde üzerinde duracağımız “fuzz” testi gibi teknikler de uygulamaların beklenmedik girdiler karşısında tepkilerini ortaya koyar. Fuzzing tekniği ile programcının amacı rastlantısal girdiler karşısında uygulamanın zayıflığını ve beklenmedik tepkilerini ölçmektir. Fuzz testleri web uygulamalarının geliştirilmesinde ayrı bir önem taşır. Bu nedenle yeni yüzyılın web firmaları tarafından büyük bir titizlikle uygulanır. Çünkü uygulama internet üzerinden çok daha geniş ve takibi imkansız büyüklükte bir kitleye ulaşır.
Fuzz testleri uygulama kalite kontrol uzmanlarının bile gözünden kaçabilecek çok karmaşık açıkları ortaya çıkarabilir.
Karmaşık uygulamalarda hatalı olabilecek her kodu önceden tahmin etmek neredeyse imkansızdır. Örneğin Windows 7’da ortalama 50 milyon satır program kodu bulunduğu düşülürse Microsoft’u sıkça konuşulan Windows güncellemeleri ile yargılamadan önce iki kez düşünmemiz gerekir.
Çekiç etkisi
Fuzz testleri sürekli olarak anlamsız girdilerle uygulamanın adeta büyük bir çekiçle dövülmesine benzetilebilir. Fuzz testleri girdilerin yapılacağı kullanıcı gereksinimi duymadığından yazılım firmalarına kalite kontrol bütçesinden tasarruf da sağlar. Microsoft, Apple ve Google gibi yazılım devleri bu nedenle masrafsız kabul edilen fuzz testlerini yazılımın destek ömrü tamamlanana dek devam ettirirler. Fuzz testlerinin bir diğer avantajı da basit olmasıdır. Belirlenen noktaları hedef alan fuzz testleri kolayca uygulanabilir. Kısa süre önce fuzzing testleri sayesinde Windows 7 üzerinde önemli bir güvenlik açığı ve iPhone üzerinde SMS ile ilgili bir hatanın ortaya çıkarıldığı rapor edildi.
Kola makinelerinde fuzz testi deneyimi
Bu olay 1980 yıllarında kola makinelerinin Bahama’larda ilk kez kullanılmaya başlandığı zamanda geçiyor. Bahama adalarına Amerika’dan ithal edilen kola makineleri doğal olarak üzerlerinde sadece 25 cent kabul eder uyarısı taşıyor. Bahama para birimi Amerikan dolarıyla aynı değere sahip ve her ikisi de her yerde kabul görüyor. Kola makinesiyle o yıllarda ilk kez karşılaşan uzmanımız meraklı denemelere koyuluyor ve eline geçen her metal parçasını makine üzerinde deniyor. Ardı ardına metal pul, 25 Bahama centi, 10 Amerikan centi, hepsi makineden geri düşüyor. Ta ki 10 Bahama centini deneyene dek. Makine 10 Bahama centini 25 Amerikan centi olarak algılıyor ve makineye ard arda 30 Bahama centi daha attığında ekranda 1 dolar kabul edildiğini görüyor.
Yeni Türk Lirası’nın ilk kullanıma geçtiği zamanlarda benzer bir örneğin Avrupa’da kola makineleriyle yaşandığı da sıkça anlatılır. Bu yöntem teorik olarak gayet basit bir işlem gibi görünmesine rağmen pratikte bir o kadar da karmaşık hale geldiği görülüyor.
Fuzzing nasıl uygulanır?
Piyasada bu iş için hazırlanmış çok sayıda ürün bulabilirsiniz. Örneğin Micheal Eddington tarafından geliştirilmiş Peach Fuzzing platformu (http://peachfuzzer.com), Immunity firmasının Spike (http://www.immunitysec.com/resources-freesoftware.shtml) ve Microsoft’un MiniFuzz (http://go.microsoft.com/?linkid=9678112) yazılımlarından ücretsiz olarak yararlanabilirsiniz. Codemıcom Defensics firmasının Codemicom ve Beyond Security’nin BeStrom yazılımları da fuzz testi yazılımlarına verebileciğimiz ticari örnekler.
Web uygulamaları için kullanılan fuzzing yazılımları çok daha gelişmiş. Çoğu test yazılımı uygulamanın girdilere vermesi gereken normal cevapları anlayarak sapma ve hata belirtilerini ortaya çıkarabiliyor. Örneğin meşhur SQL Injection açığını test etmek için girdi tırnak içerinde bir metin olabiliyor. Eğer girdiye veritabanı hatası ile karşılık verilirse testçi potansiyel bir hatanın varlığını belirlemiş oluyor.
Web tabanlı olmayan uygulamalar için fuzz testleri belirsizler içeriyor. Bu testler dosyaların, ağ trafiğinin ve API parametrelerinin değiştirilmesi yöntemiyle gerçekleştiriliyor.
Örneğin fuzz testi;
1) Tesadüfi girdiler oluşturuyor ya da mevcut girdileri rastlantısal olarak değiştiriyor.
2) Bu girdileri uygulamaya gönderiyor.
3) Uygulamanın çöküp çökmediğini kontrol ediyor. Bu işlem buffer overflow gibi muhtemel çökme nedenlerini ortaya çıkarıyor. Eğer çökmeye neden olmayan açıkları arıyorsanız fuzzing yönteminden otomasyon yardımıyla yine yararlanmanız mümkün.
Kola makinesi örneğine geri dönersek eğer makine piyasaya sürülmeden önce fuzzing yöntemi uygulanmış olsaydı farklı girdiler karşısında alınan tepkiler gözlemlenebilir ve testin maliyeti karşılaşılan sonuçtan çok daha ekonomik olabilirdi.
Gereksinimlerin ötesinde
Çoğu güvenlik açığı aslında şartların sağlanması için tanımlanan gereksinmilerin hlalinden değil eksik gereksinimlerden kaynaklanır. Örneğin basit bir gereksinim tanımlayalım: “Kullanıcı Y girdisini verdiğinde yazılım Z çıktısını vermeli”. Gereksinimleri test etmek oldukça kolay. Y girdisini uygulayalım ve Z çıktısını bekleyelim. Oysaki gereksinimlerin kontrol edilmesi en kritik nokta, çünkü güvenlik açığı testleri gereksinimlerin çok daha ötesini önceden düşünmüş olmalı.
Bu testlerin ardında çok sayıda varsayım ve sabit kullanılmalı. Örneğin eğer girdi kredi kartı numarası gibi hassas bir bilgi ise bu bilgiyi geçici olarak bile olsa güvensiz bir yerde saklamak iyi bir fikir olmaz. Programcılar bunu gözden kaçırabilir ve tasarım uygulamayı risk altında bırakabilir. Bir projeye güvenlik kalitesini aşılamak için kalite kontrolcüler fuzzing ve benzeri teknikleri uygulayarak aşağıda belirtilen gereksinimlere ve sorulara cevap almayı hedefler:
- Sistemin yapmaması gerekenler ne olabilir?
- Girdiler, fonksiyonlar ve bilgi nasıl kısıtlanmalı?
- Güvenlik özellikleri yeterli mi ve kodlar güvenli mi?
Sistem açıkları geliştirme sürecinin her aşamasında yoğun olarak uygulanmalıdır. Ana güvenlik gereksinimleri yetersiz ve kötü tanımlanmış olabilir. Yapısal zayıflıklar tasarım aşamasında hesaplanmalıdır. Hatta programcı savunmasız bir fonksiyonu hedefleyerek girdiler oluşturup uygulama üstünde kullanabilir. Güvenlik testi araçları bu açıkları hedef alır ancak bu araçların da sınırları olduğu unutmamalı.
Geçtiğimiz yıllarda çok sayıda yazılım güvenliği testi aracı kullanıma sunuldu. Çoğunluğu fuzzing testlerini de içeren bu araçlar genelde testlerin güvenlik yönüne ağırlık verdiler. Sonuç olarak çok sayıda açık ortaya çıkarıldı ancak bir o kadarı da gözden kaçtı. Konu güvenlik testine gelince test uygulamalarına garanti olarak değil sadece erişim noktamızı uzatan bir kol olarak bakmalıyız. Kısacası güvenlik testinin başarısının onu yanlış yönlerde kullanmak isteyen yaratıcı insan beynine bağlı olduğu esasını unutmamalıyız.
Örneğin bir kaynak kodu tarayıcı ya da güvenlik özelliklerine sahip derleyici genelde bilinen açıklara neden olacak hataları arar. Bu sayede kodlar doğru da olsa programcı muhtemel zayıf noktaya karşı uyarılır. Bu araçlar her ne kadar geliştirme test aşamalarına yardımcı olsalar da resmin sadece bir yönünü görürler. Günümüzde çoğu uygulama diğer uygulamalarla bağlı ve etkileşimli olarak çalışır. İstatistiksel olarak bir modülün ya da uygulama kodunun taranması çalışan bir uygulamanın düşmanca girdilere karşı vereceği tepkiyi göstermez. Bu açığı hedef olan dinamik güvenlik araçlarından yardım almanız gerekir. Uygulama tarayıcıları ise web tabanlı uygulamalarda potansiyel güvenlik açıklarına neden olabilecek şüpheli girdiler oluşturmayı hedefler. Yetersiz de olsalar bu araçlardan en azından kolay görünen ve sık rastlanan açıkları belirlemek için yararlanmanız önerilir.
Yapısal zayıflıklar
Uzmanımızın başından geçen kola makinesi örneğine geri dönelim. O dönemde fark etmediği ya da fark edipte bizimle paylaşmaktan çekindiği bir başka gerçek daha var. Aslında bu açık uzmanımızın çocukluk yıllarındaki masum macerasını ve kola makinesinin basit hatasını çok daha büyük bir soruna dönüştürebilirdi. Kola makineleri atılan metal paraları aynı para haznesi içerisinde bir kumbara gibi biriktirir. O dönemlerde sadece metal paranın ağırlığı ve boyutlarıyla çalışan sistem ele alınırsa denenmesi gereken bir fuzz testi de biz yaratalım. Makineye atılan Bahama centleri ile kola almak yerine acaba parayı geri iade et düğmesine basıldaydı ne olurdu? Muhtemelen attığınız metal paralar yerine aynı kumbarada biriken paralardan dört 25 centlik geri alacaktınız. 40 Bahama centine karşılık 1 Amerikan doları. Çok da kötü bir yatırım sayılmaz!
Uzun lafın kısası muhtemelen o dönemlerde kola makineleri, market çalışanından kar edileceği düşünelerek büyük bir güvenle tasarlanmış ve tüm müşterilerin baklenen girdileri vereceği tahmin edilmişti. Kola makinesi tasarımı atılan nesneleri iyi tanımlayamayarak sadece bir açığa neden olmuyor aynı zamanda nesneleri karıştırarak bir başka sorun doğuruyordu. Buradan çıkaracağım ders sadece uygulama geliştirirken değil hayatın içerisinde insan girdisi gerektiren tüm sistemlerde tasarım aşamasında güvenliği çok iyi ele almak gerektiği olmalı. Bu tür sorunlar güvenlik testlerinin daha bütünsel ele alınmasıyla çözümlenebilir.
Yazılım güvenliği kalitesi her ne koşulda olursa olsun geliştirme aşamasına entegre edilmelidir. Testler gereksinimlerin, girdilerin ve tasarımın oluşturulmasıyla başlamalı geliştirme ve test aşamalarında devam etmeli, kullanıcıya sunum ve destek aşamalarında da sürdürülmelidir. İyi haber bu iş için yararlanabileceğin çok geniş kaynakların bulunuyor olması. Microsoft kendi yazılım güvenlik geliştirme döngüsünde kullandığı çok sayıda araç ve işlemi kullanıcılarıyla da paylaşıyor. Aynı şekilde SAFEcode forumu da (http://www.safecode.org) dünyanın en büyük yazılım geliştiricisi firmalarının en iyi örneklerini internetten bizlerle paylaşıyor.
6,969 total views, 1 views today
