Ugulamalardaki Temel Güvenlik Açıkları ve Alınması Gereken Önlemler

Şifre Güvenliği

Uygulamalarda şifre karmaşıklığı ile ilgili temel konulara dikkat edilmelidir. Aksi takdirde sistemler kolayca tahmin edilebilir şifrelere izin veriyorsa saldırganlara kolay hedef olabilir.

Önlem:
-Şifreler en az 6–8 karakterden oluşmalıdır
-İçerisinde en az 1 adet alfanumerik bir karakter olmalıdır.
-Mümkünse 1 adet noktalama işareti içermelidir.
-Parola değişikliğinde en azından önceki 2 parola ile aynı olmamalıdır.

Login Güvenliği

Sisteme login olma sırasında maksimum hatalı şifre girme sınırı konulmalıdır. Aksi takdirde herhangi bir otomatize client ile deneme yöntemini kullanarak kullanıcı adı ve şifre tahminlemesi yapılabilir.

Önlem:
-Maksimum 3 hatalı şifre girişi yapıldığında kullanıcı kilitlenmelidir.

Cookie Güvenliği

Cookie’ler sistemlerimizde genellikle kullanıcının kimliğine dair bilgileri browserler üzerinde saklamak için kullanılmaktadır. Örneğin kullanıcı uygulamaya login olduğunda serverde uygulama bir session oluşturur ve bunun id bilgisini cookie ile browsere gönderir. Browserlerde bu bilgiyi kolaylıkla görebilirsiniz. Bu bilgi eğer erişilebilir durumdaysa farklı yöntemlerle saldırganlar bu bilgileri elde edebilir.

Önlem:
-Cookilerin javascript ile erişilmesini engellemek “httpOnly” flaginin olması gerekmektedir. Bu sayede browserde çalıştırılan bir javascript kodu ile cookie bilgisine erişilemez, browser bunu engelleyecektir.
-https protokolü kullanlıyor ise “secure” flaginin olması gerekmektedir. Bu sayede browser requestleri gönderirken yalnızca https protokolü kullanıldığında cookie bilgilerini requeste ekleyecektir.
-Cookielere bir yaşam süresi verilmelidir.

URL Güvenliği/Form Güvenliği

Hassas bilgilerin url/Form üzerinde taşınması riskler oluşturmaktadır. Aşağıdaki linkte yapılan işlemde saldırgan “user” bilgisini değiştirerek farklı bir kullanıcının şifresini değiştirebilir.

http://www.abc.com/sifredegistir?user=demo&pwd1=123&pwd2=123

Önlem:
-Bu tarz bilgilerin url/Form üzerinde değil session gibi server side’de kullanıcıların doğrudan erişemediği alanlarda taşınmalıdır.
-jsf deki ViewScope bu konuda ciddi bir kolaylık sağlamaktadır, jsf projelerinde ViewScope kullanılarak hassas bilgiler ManagedBean’lar üzerinde tutulmalıdır.

Dış Sistemlerle Yapılan Entegrasyonların Güvenliği

Uygulamalar dışarıdan uygulamamıza ya da uygulamamızda dış sistemlere entegrasyonlar yapıyoruz. Bunun için webservisler yaratıyoruz ya da çeşitli teknolojiler ile entegrasyon kanalları oluşturuyoruz. Dışarıya açtığımız herhangi bir adres saldırganların hedefinde olabilir.

Önlem:
-Dışarıya açtığımız web servis ya da adreslerin bir kullanıcı doğrulaması ile erişilebilir olması gerekli
-Gönderilen verilerin erişen kullanıcının yetkisine göre sağlandığından emin olunmalı
-Dışarıdan aldığımız verilerin diğer maddelerde bahsettiğim filtre/kontrollerden geçmesi gerekli

ssl Bağlantı

Uygulamalarımızda sistem ve veri güvenliği açısından https protokolü kullanılmalıdır. Aksi durumda networkü dinleyen bir saldırgan kullnıcılara/şirkete dair bilgileri ele geçirebilir. Kullanıcının Session ID bilgisi ele geçirildiğinde o kullanıcı gibi sisteme erişilebilir.

Önlem:
-Sunuculara https protokolü için ssl sertifikaları kurulmalıdır.

csrf Koruma(Cross Site Reference Forgery)

csrf, Özellikle get request’leri ile oturum açmış kullanıcının yetkilerini kullanarak oturum açtıkları sistemde çeşitli işlemler yapmalarını sağlayarak saldırı yapma çeşididir. Örneğin sistemde şifre değiştirme sayfası olsun ve bu sayfa get requestlerini de dinlesin. Bu durumda otrurum açmış olan kullanıcıya bir e-mail içerisinde aşağıdaki html content gönderildiğini varsayalım.

<“img src = “http://www.abc.com/sifredegistir?user=demo&pwd1=123&pwd2=123″/>

Bu durumda oturum açmış kullanıcı e-maili aynı browserde açtığında kullanıcı www.abc.com sisteminde session oluşturduğu için sisteme yukarıdaki request gider, saldırgan kullanıcının parolasını belirlediği şekilde değiştirmiş olur ve sistemde istediği şeyi yapabilir.

Bu konuyu sadece böyle kısıtlı düşünmemek gerekir, örneğin bir get requesti ile onay mekanizmasının çalıştığı bir ekranda da bir şeyin onaylanması bu yöntemle sağlanabilir.

Önlem:

-Captcha ya da csrf_token gibi her requestte değişen bilgi doğrulama mantığı kullanılabilir.
-Transactional işlemlerde get yöntemi kullanmamak gereklidir.

HTML formlara “csrf_token” adında bir hidden alan eklenir. Bu alan form her render edildiğinde farklı değer alır bu bilgi server side’da saklanır. Kullanıcı bu formu post ettiğinde form datasi ile gelen “csrf_token” ile serverde tutulan token bilgisi aynı ise istek işleme alınır. Aksi takdirde işlem yarıda kesilir.

Bu önlemler özellikle public sayfalarda kolayca sisteme attack yapmayı önlemeye yardımcı olur.

xss (Cross Side Scripting) Koruma

Cross site scripting (xss), html kodlarının arasına istemci tabanlı kod gömülmesi yoluyla kullanıcının tarayıcısında istenen istemci tabanlı kodun çalıştırılabilmesi olarak tanımlanır.

Uygulamada bir form içeren sayfa olduğunu düşünelim; bu formda kullanıcıdan çeşitli bilgiler alınıyor ve veritabanına kaydedilip sonrasında yine başka bir sayfada listeleniyor. Eğer saldırgan bu form bilgileri içerisinde kullanıcının cookie bilgilerini okuyan ve başka bir url‘e get metodu ile gönderecek bir javascript eklerse oturum açan kullanıcının Session ID bilgisini ele geçirip sisteme o kullanıcının yetkileri ile erişebilir. Browser üzerinde client side’da yapılabilecek herşeyi yapabilir.

Önlem:
-Kullanıcılardan alınan verilerdeki javascript, html içeren veriler filtrelenmelidir.

sql Injection Koruması

Uygulamalarımız temelde crud işlemleri yapmaktadır. Bu işlemleri gerçekleştirirken sql scriptleri kullanıyoruz. Ve veritabanına gönderdiğimiz bilgiler kullanıcıların girdiği veriler olmaktadır.

Örneğin delete http://www.abc.com/tipsil?id=123 url‘i ile 123 id’li kaydı silecek bir işlem tetikleyelim. Ve bunun sonucunda aşağıdaki kodun çalıştığını düşünelim;

stmt.executeUpdate(“delete from tipler where id = “+tipId);

Saldırgan url‘i aşağıdaki gibi değiştirirse tablodaki tüm kayıtları silebilir;

http://www.abc.com/tipsil?id=123 OR 1=1

Bu işlem sql injetion olarak tanımlanmaktadır. Bu yöntemle uygulamalara çok ciddi zararlar verilebilir.

Önlem:
-Her türlü çalıştırılan sql scriptini “PreparedStatement” kullanarak çalıştırılmalıdır.
-jpa,Hibernate vb. gibi orm araçları kullanılmalıdır
-DB prosedürleri kullanılabilir
-Kullanıcılardan alınan verilerdeki tırnak,çift tırnak, ampersand, büyük, küçük vb. gibi sql scriptlerini bozacak veriler filtrelenmelidir.

Uygulamalardaki Güvenlik Açıklarının Tespiti

Uygulamalarda güvenlik açıklarını çeşitli araçlar ile yukarıdaki başlıklar kapsamında tespit edebiliriz. Aşağıda bazı opensource araçları bulabilirsiniz;

  • OWASP Zed Attack Proxy (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)
  • SqlMap (http://sqlmap.org)
  • Wapiti (http://wapiti.sourceforge.net)

Bizim tercih ettiğimiz uygulama owasp Zed Attack Proxy dir. Bu uygulamanın kullanımı temel olarak şöyledir;

-Uygulama açıldıktan sonra “Quick Start” ekranındaki “url to attack” bölümüne test etmek istediğiniz adresi yazın.

-Sonra “Launch Browser” butonu ile bir browser açılacaktır. Bu browser Zend Attack üzerindeki proxy ile çalışır, bu sayede belirtilen adreste yapılan tüm requestler kaydedilir. Browser açıldıktan sonra test etmek istediğiniz senaryoda uygulamada gezinin ve gezintiyi tamamlayın.

-Sonra Sol tarafta “Sites” bölümünde gezindiğiniz adres klasörlenmiş olarak görüntülenecektir. Bu klasöre sağ tıklayıp “Attack > Active Scan” adımlarını izleyerek testi başlatın.

-Sonuçları alt bölümde bulunan “Alerts” kısmında görülecektir.

Software / Yazılım Testi Nedir?

Yazılım geliştirme yaşam döngüsü içerisinde testin önemi yazılımdaki kalitenin seviyesi ile doğru orantılıdır. Test bir bakış açısı ile yazılımın kalitesini arttırmak için önemli bir konudur. Yazılım geliştirme sürecinde bu konu önemsenmeli ve ciddi politikalar belirlenip benimsenmelidir.

Yazılım geliştirme yaşam döngüsü içerisinde bulunan test konusunun ne ve nasıl olması gerektiğine dair konuları aşağıdaki slaytlarda bulabilirsiniz.

SDLC – Software Development Life Cycle Nedir?

Yazılım geliştirmede, sadece çeşitli teknik ve tenkolojileri bilerek kod geliştirmek yeterli değildir. Başta bunun bir süreç olduğunu bilmek gerekmektedir. Yapılan iş bir problemi çözmeye yönelik çalışmalar yapmayı içeriyor ve bu işin nihayetinde bir hedef vardır. Bu hedefe nasıl gidilebileceğine dair çeşitli yöntemler ve pratikler vardır. Aşağıda bu sürecin nasıl olması gerektiğine dair çeşitli yaklaşımları bulabilirsiniz.

Nedir Docker?

dockerKısaca ifade etmek gerekirse sanallaştırma konusunda en temelde olan kaynak kullanımına optimizasyon sağlayan bir araç olarak nitelenebilir. Bunu nasıl yapıyor derseniz; VMWare,VirtualBox vb. gibi araçların çalışma mantığı şöyledir; fiziksel host makinenin kaynaklarını belirtilen ölçülerde kullanarak bir işletim sistemi çalıştırır. İşletim sisteminin de bir yazılım olduğundan belirli ölçülerde memory,cpu vb. kaynağına ihtiyaç duymaktadır. Bu da host makinenin kaynaklarını daha fazla tüketmeye sebep olmakta.

Docker ise şunu diyor; madem amaç ayrıştırılmış kaynaklar üzerinde bir/birkaç uygulamayı yalıtılmış olarak çalışırtırmak ise, bunu ayrıca bir işletim sistemi olmadan da yapabiliriz. Ve dedikleri gibi de yapıyorlar. Docker ile host makine üzerinde uygulamalar birbirlerinden yalıtılmış şekilde çalışabiliyor hale geliyor. Bu sayede uygulamaları yalıtmak, farklı adresler,portlar vermek için ekstra bir işletim sistemi çalıştırmaya gerek kalmıyor. Ve böylece işletim sistemi çalıştırmak için gerekli olan kaynağı amacınıza yönelik kullanabilir hale geliyorsunuz. Aslında buraya kadar olan kısmı daha öncede farklı araçlar ile yapılabiliyordu. Bildiğim Solaris üzerindeki Zone’lar bunu sağlıyordu. Docker’in farkı ise buradan sonra başlıyor. Bu aşamaya kadar yaptığı, bu tarz özellikleri kolay kullanılabilir hale getirmesi.

Docker aslında bir uygulama sanallaştırma aracıdır dersem yanlış olmaz sanırım. Unix/linux sistemler için tasarlanmış, fakat windows üzerinde de kullanabiliyorsunuz. Docker daha önce bu tarz işler için geliştirilen uygulamalar bir araya getirilerek oluşturulmuştur.

Tek yaptığı bu değil tabiki. Başka neler yapabiliyor; sanallaştırmak istediğiniz uygulamalar için configürasyonlar oluşturuyorsunuz(uygulamayı şuradan yükle, bu parametreleri kopyala, şu port ile çalıştır vb.). Bu konfigürasyon dosyalarının build edilmiş haline image deniyor. Image’lar üzerinde değişiklik yapıp değişiklikleri yönetebiliyorsunuz. Bu source versioning aracı olan git’e benziyor. Sonra bu image’ları dockerhub denilen bir repositorye yükleyip herkesin erişip kullanabileceği hale getirebiliyorsunuz. İsterseniz ücretli bir hesap ile dockerhub üzerinde private repolar oluşturabilirsiniz. Oluşturulan bu imajlar her sistemde çalışabilir nitelikte oluyor, bu paket eksik bunun versiyonu farklı gibi sorunları bertaraf ediyor. Geliştirme ortamında çalışan uygulamanın test ve production ortamında da çalışacağını garanti ediyor.

Sonrasında oluşturulan bu imajları container denilen, uygulamaları yalıtabilen sanal ortamlar üzerinde çalıştırıyor. Dockerhub’a yüklediğiniz imajı çalıştırmak için yapmanız gereken docker ortamına pull etmek ve çalıştırmaktır.

Docker için edindiğim izlenimleri yalın bir şekilde paylaşmak istedim 😉 Teknik olarak bu anlattıklarımın nasıl yapıldığına dair ayrıntıları paylaşmaya çalışacağım.

Test Driven Analysis

İş süreçlerimizde analizin çok önemli olduğunu düşünenlerdenim. Maalesef öyle zamanlar geliyor ki işle uğraşmaktan çok, işi verenlerle uğraşmak zorunda kalıyorsunuz. Bu konunun literatürde detaylarını hiç araştırmadım. Ama yaşananlar insana “ya kesinlikle test yönelimli analiz yapılmalı” cümlesini kurdurtuyor.

Neden Böyle? diye sorduğumda…

Analiz eksikliklerinin bence en önemli sebebi yönetimdeki anlayıştır. Birçok yerde kurallar vardır ama büyük oranda bu kurallara uyulmaz. Konulan kurallar da zamanla verimsiz hale gelir. Bir zaman sonra artık bu kurallar sadece denetimlerde gündeme gelir ve sonraki denetime kadar raflarda kalır.

Yukarıda neden en önemli sebep yönetimdeki anlayış dediğimi biraz daha açıklayacak olursam; kimse durup dururken birşeyleri standartlaştırmanın peşine düşmez. Neden kendi kendine kurallar koyup kalıba girsin. Tabiki standartlaşmanın asıl amacı ölçümleyebilmektir. Standart olmayan birşeyi belirli kriterlere göre ölçmek çok zor olsa gerek.

İş süreçlerinizi ölçümleyemezsiniz nerede problem olduğunu göremezsiniz. Bunu göremezseniz işinizi iyileştirip, konforunuzu arttıramazsınız vb…

Tabi böyle bir iyileşmenin ihtiyaç olduğunu anlayabilmek en önemli mesele 🙂 Eğer dünyada/dünyanızda neler olup bittiğini görmüyorsanız, farkında değilseniz, nasıl olsa işler yürüyor öylese sorun yok diyorsanız ilerleme kaydetmek neredeyse imkansız oluyor.

Bunlar iş süreçlerinin daralıp maalesef e-mail ile yürüyen bir akışa kadar inmesine sebep oluyor. Yönetici açısından bakınca; kimse süreci denetlemiyor, işi yapanlarda bir şekilde e-mail içerisindeki söylenenleri yapıyorlar. İşin detayında yirmi kez de değişiklik yapılsa, komple de değişse problem olarak görülmüyor.

Ben bir analist değilim, bu işin eğitimini de almadım. Sadece yaşadıklarıma dayanarak temel düzeyde yorumlar yapıyorum. Bir konuyu analiz etmek, konuyu bütün detayları ile ortaya koyabilmek olmalı. Tüm detayları ortaya koymak demekse konuya kafa yormak, anlaşılmayan noktaları tartışmak, netleştirmek olmalı.

Eğer bu kafa yorma süreci işlemiyorsa iş delik deşik oluyor. Ortaya karmaşık, bakım maliyeti yüksek bir iş çıkıyor. Çünkü iş anlaşılmadan yapılmaya başlanıyor, sonra müşterinin karşısına çıkıyor, müşterinin beklentisini karşılamammış oluyor. Sonra tekrar müşterinin taleplerine göre değişiklikler yapılıyor vb. Bu değişiklikler çok köklü de olabiliyor.

Bu kadar sorunu yaratmak ve yönetmek yerine dikkatli bir analiz süreci ile herkesin memnun olacağı bir iş yürütmek daha mantıklı ve kolay değil mi?

Analizin bir de test driven olduğunu düşünsenizya ne kadar muhteşem olur 🙂 İşi yapanlar sadece kendi işlerini yaparlar, analistlerin işlerini değil.