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