spacer.png, 0 kB
Bilgi için: bilgi at bilgiguvenligi gov tr   

 

spacer.png, 0 kB
spacer.png, 0 kB
Oturum Açma Sistemleri Tasarımında Güvenlik Yazdır E-posta
Gökhan Muharremoğlu, PwC   
02.04.2012

Bu yazıda Kurumsal Ağlarda En Çok Karşılaşılan Açıklar makale serisinin dördüncüsü olarak Oturum Açma Sistemleri Tasarımında Güvenlik konusu işlenecektir.

Güvenlik açısından bakıldığında neredeyse her zaman en az bir adet açığın bulunabileceği sistemler, oturum açma adımlarının geçtiği sistemler olmaktadır. Özellikle birçok kurum, kendi bünyesindeki yazılım ekibine yaptırdığı uygulamalarla bazı bilgi kaynaklarının yönetimini hedeflemektedir. Bilgi kaynaklarına olan erişimin en büyük gereksinimlerinden biri olan yetkilendirme gereksinimi ve beraberinde gelen bir oturum açma sisteminin tasarlanması adımı, bu bağlamda yazılımcıları ve kurumları bekleyen önemli konu durumundadır.

İster kurum içinde çalışan bir yazılım ekibinin oluşturmasıyla, ister paket olarak hazır alınmış bir uygulamanın kullanılmasıyla veya  dış kaynaklı bir ekibin oluşturmasıyla olsun, her oturum açma sistemi son kullanıcıdaki kullanıldığı şekliyle güvenlik konusunda uzman kişilerin yorumuna ihtiyaç duymaktadır.

Teknik olarak ele almak gerekirse oturum açma sistemlerindeki olası tehditlerin genel sınıflandırmasını şu şekilde yapılabilir:

Ağ mimarisi kaynaklı tehditler

İnternet üzerinden denetlenebilecek ağın, OSI Modelinde 7. katman dahil olmak üzere 7. katmana kadar olan yapının bilinen ve kabul görmüş penetrasyon teknikleri ile ele denetlenmesidir.

Bu seviyede hedeflenen sonuç, ağ cihazları ve ağ mimarisi kaynaklı açıkları bulup tespit etmektir. Örnekle bu seviye, Web uygulaması gibi 7. katmanın üzerinde koşan yapıyı kapsamaz. Bunun yerine, Web uygulamasının ağ içindeki iletişimini ele alır.

Bu tetkiklerde zayıf SSL algoritmaları, konfigürasyonu sıkılaştırılmamış SNMP servisleri, ağ üzerinde IP filtrelemeye tabi tutulmamış yönetim arabirimleri gibi bulgulara rastlanabilir.

Bu tehditleri OSI 7. Uygulama Katmanına kadar (Uygulama Katmanı dahil olmak üzere) olan katmanlarda meydana gelebilecek açıklardan oluşturmak mümkündür.

Zayıf SSL, ARP Poisoning, Man In The Middle, Pass the Hash saldırıları gibi saldırılar bu katmanlarda meydana gelirler. Örnekle açıklamak gerekirse; Cleartext yayında olmaması gereken bir panelin tüm kimlik bilgilerini Cleartext olarak kabul etmesi hem ağ hem de yazılım tasarımı kaynaklı bir tehdittir.

Mantıksal sistem tasarımı kaynaklı tehditler

Bir sistem tasarlanırken sistemi oluşturan parçaların bir biri ile olan mantıksal ilişkisinden yola çıkarak meydana gelmiş açıklar bu tehditleri oluşturabilirler. Bir oturum açma sistemi “Ağ, Yazılım, Kullanıcı ve Kullanıcı Arabirimleri” bileşenleri ile oluşturulan bir bilişim sistemidir. Bu bileşenlerin bir biri ile ilişkisinden kaynaklı açıklar da tehditler oluşturmaktadır. Örnekle açıklamak gerekirse;  sistemde çok kritik ve sadece kurum içinde yayına açık olması gereken bir kullanıcı panelinin İnternete açık yayında tutulması bir mantıksal sistem tasarımı hatasıdır. Para transferinin olduğu sistemlerde “-1” miktarda giriş yapıldığında hesaptaki miktarın artması kodlama esnasında mantıksal yapı veya benzeri nedenler ile ortaya çıkmış olabilir. Yazılım içinde yapılan aşırı yetkilendirme gibi güvenlik ihlalleri veya bir alış-veriş uygulamasında ürünün para ödeme adımından önce kargoya verilmesi gibi bir uç örnek de mantıksal sistem tasarımı kaynaklı tehditlere örnek gösterilebilir.

Yazılım tasarımı kaynaklı tehditler

OSI katmanları ile yazılımın ortak olarak bir arada bulunduğu ve yazılımın kendi yapısı dahilinde meydana gelebilecek bütün teknik açıkları yazılım tasarımı kaynaklı tehdit olarak değerlendirmek mümkündür.  Buradaki önemli nokta,  yazılım tasarımı nedeniyle meydana gelmiş bir açığı Uygulama Katmanına mal etmemektir. Örnekle açıklamak gerekirse; HTTP paketleri içinde HTTP Only işaretlenmemiş bir Cookie (çerez) Uygulama Katmanından geçen ancak yazılım tarafından oluşturulmuş bir açıktır. Aynı şekilde Zayıf SSL kullanımı ile meydana gelmiş bir açık Uygulama Katmanında meydana gelir ve bu açığı da yazılıma mal etmemek gerekir.

Oturum açma sistemlerinde çok sık rastlanan bazı açıklara değinmek faydalı olacaktır. Bu açıkların bazıları çok az bilinir olmaları nedeniyle sık rastlanan açıklar iken, bazıları da çok fazla bilinmelerine karşın gözden kaçan veya gerekli önemin gösterilmemesi nedeniyle ortaya çıkan açıklardır.

Oturum Öncesi Tanımlı Oturum Kimliği Çerezi

Web uygulamaları kimlik doğrulaması adımından başarı ile geçen kullanıcılar oturumlarını saklamak için Cookie (çerez) bilgisini kullanırlar. Yaratılan bir çerezin içeriğinde kullanıcıya ait oturum kimliği de bulunur. Bu oturum kimlikleri kullanıcı başarılı bir kimlik doğrulama adımını geçtikten sonra özel olarak hazırlanmış tahmin edilmesi zor Session Hash’lerinden oluşturulurlar ve hem sunucu tarafında hem de kullanıcı tarafında saklanırlar.

Bir çerez içeriğinde kimlik doğrulama (login) adımından önce bulunan Session Hash yani oturum kimliği başarılı bir oturum açma işlemi sonrasında da kullanılmaya devam ederse, oturum açılmadan önceki çerezi çalan bir saldırgan, kullanıcı oturum açtıktan sonra bu çerezi kullanarak sisteme yetkisiz erişim sağlayabilir. Yapılan incelemelerde kullanıcı giriş sayfalarında kimlik doğrulaması adımı geçilmeden yaratılan çerez bilgisinin kimlik doğrulaması adımından sonra da kullanılmaya devam ettiği bulgusuna erişildiği durumlarda bu açığın varlığından söz edilebilir.

Oturum açılmadan önce kullanılan çerezin oturum açıldıktan sonra kullanılan çerez ile aynı olmaması, her açılan oturum için yeni bir çerezin (oturum kimliğinin) kullanılması önerilir.

Sekmeli Tarayıcılarda Oturum Sonlandırılmaması Açığı

Günümüzde yaygınca kullanılan sekmeli browser'larda, güvenli çıkış yapmayarak, tarayıcı sekmesini kapatan bir kullanıcının oturumuna başka biri kaldığı yerden devam edebilmektedir. Bu şekilde ortak paylaşılan bir bilgisayarı kullanan kullanıcı kapadığı sekme ile oturumunu sonlandırdığını düşünürken, başka bir kullanıcı bu sekmeyi geri çağırarak bir önceki oturuma kaldığı yerden devam edebilmektedir. Bu durumda uygulamaya ait oturum browser (tarayıcı) ana penceresi kapanana kadar hayatına devam edecektir. Kullanıcıya yönelik gerçekleşebilecek başka teknik saldırılar için de zemin oluşturacaktır.

Yapılan manuel (elle) kontroller esnasında sekmeli browser'da kapatılıp tekrar çağrılan sekmeye ait oturumun kaldığı yerden devam ettiği durumlarda bu açığın varlığından söz edilebilir.

Bir sekme kullanıcı tarafından kapatıldığında, browser’ın otomatik olarak “güvenli çıkış” işlemini yapmasını sağlayacak bir oturum sonlandırma tasarımına geçilmesi önerilir.

Çerezlerin (Cookie) Secure Olarak İşaretlenmemesi Açığı

Çerezler (Cookies), istemci tarafında web uygulamasıyla ilgili herhangi bir bilgiyi, oturum numarasını vs. saklamaya yarayan ve sadece kendisinin yollandığı alan adı (domain) için bilgilerini veren bir araçtır.

HTTPS üzerinden yollanan çerezler eğer “Secure” olarak işaretlenmez ise HTTP üzerinden şifresiz olarak da gönderilirler. Bütün bir uygulama boyunca oturum işlemlerinin geçtiği her adımda HTTPS kullanılan bir sistemde çerezleri “Secure” olarak işaretlememek, bir saldırganının oturum bilgisini HTTP üzerinden elde etmesi ile sonuçlanabilir.

Eğer bütün uygulama kapsamında HTTPS üzerinden şifreli bir bağlantı gerçekleştiriliyorsa, HTTP başlıklarındaki Set-Cookie özelliğine Secure deyimi eklenmelidir.

Yanlış Kullanıcı Girişinde Hesabın Bloke Edilmesi

Web uygulamaları brute force (kaba kuvvet) saldırılarına karşı kullanıcı parolalarını korumak amacıyla belirli sayıda hatalı giriş denemesi sonucunda kullanıcı hesaplarını kilitlerler. Bu kullanıcı bilgilerinin ele geçirilmesini engellemek adına iyi bir yöntem gibi gözükmekle beraber, kullanıcı adlarını tahmin eden ya da rastgele kullanıcı isimleri deneyen bir saldırgan kasten belirlenmiş sayıda hatalı giriş yaparak o kullanıcıların hizmet almasını engelleyebilir.

Kilitlenen hesap için hizmet engelleme saldırısı gerçekleştiğinden bu özellik kaldırılarak yerine belirli sayıda hatalı giriş denemesinden sonra kullanıcı adı ve parolanın yanında, giriş yapanın bir makine değil insan olduğunu ayırt etmek amacıyla CAPTCHA talep edilmelidir. Böylelikle kaba kuvvet (brute force) saldırılarına karşı önlem alınmış olunacaktır.  Bununla beraber, bu özellik kullanılmak isteniyorsa, sadece kullanıcı adı yerine, kullanıcı adı ve IP adresinin eşleştirme yapılarak kullanılması daha doğru bir tercih olacaktır. Böylece CAPTCHA uygulamasını çözen bir saldırgan, denediği kullanıcı adı için kendi IP adresinin erişiminin engellenmesi durumuyla karşı karşıya kalacaktır.

Kullanıcı Adı Varlığının Tespiti

Kullanıcı giriş ekranları verdikleri hata mesajlarıyla sistemde hali hazırda var olan kullanıcılar hakkında bilgi vermemelidirler. Aksi takdirde bir saldırgan, bu bilgiden istifade ederek, bir kullanıcı adına yönelik saldırı gerçekleştirebilir.

Örnek vermek gerekirse:

Sistemde “yonetici” adıyla kayıtlı olan bir kullanıcı için yanlış parola girildiğinde, “Parola hatalıdır.” mesajı yerine “Kullanıcı adı veya parola hatalıdır.” Mesajının kullanılması, sistemde bu kullanıcı adının kayıtlı olduğuna dair bilgiyi sızdırmayacaktır. Hata mesajlarının kullanıcı adları hakkında bilgi vermeyecek şekilde yapılandırılması önerilmektedir.

Siteler Arası İstek Sahtekârlığı (CSRF)

CSRF saldırısı yapabilmek için saldırgan, belirli bir işlemi gerçekleştiren bir URL (kötü niyetli bir HTTP isteği içeren) hazırlamalı ve bir kullanıcının bu URL’i ziyaret etmesini sağlamalıdır. Bunu takiben ziyaret edilen web uygulaması üzerinde istenilen işlem başarıyla kullanıcının haberi olmadan gerçekleştirilebilir. CSRF saldırılarının en büyük hedefi etkilenen web uygulaması kullanılarak kullanıcıların isteği dışında web işlemlerinin (kullanıcı bilgilerinin değiştirilmesi, web uygulaması üzerinde parasal işlemler yapılması gibi) gerçekleştirilmesidir.

Web uygulamalarının CSRF saldırılarından etkilenmemesi için aşağıdaki önlemlerin bir veya birkaçının gerçekleştirilmesi tavsiye edilmektedir:

  • Form verilerinin yollanacağı alanlarda “hidden input” değeri olarak, random belirlenmiş bir oturum id’sinin (Session Hash) kullanılması.

  • URL sonlarına eklenecek bir  “Random Session Hash” kullanılması.

  • Form verilerinin yollanacağı alanlarda CAPTCHA kullanılması.

  • Üye girişi yapıldıktan sonra referrer kontrolünün, her GET ve POST işlemi için yapılması.

Yukarıda listelenen alınabilecek önlemlerin her biri CSRF saldırılarına karşı direncin artırılmasına yardımcı olabilecek, ancak tek başlarına bu tip saldırıları engellemek için yeterli olmayabilecek önlemlerdir. Bu yüzden bu önlemlerin bir arada hayata geçirilmesi önerilmektedir.

Siteler Arası Komut Çalıştırma (XSS)

Siteler arası komut çalıştırma açıkları, web uygulamasının kullanıcılarına yönelik saldırılar düzenlenebilmesine imkân veren güvenlik açıklarıdır. Bu tip açıklar, bir web uygulamasının, verilen http cevabında kullanıcı tarafından sağlanmış bir girdiyi kontrol etmeden kullanmasıyla oluşur.

Bu türde bir saldırı yapabilmek için saldırgan, belirli bir işlemi gerçekleştiren bir URL hazırlamalı ve bir kullanıcının bu URL’i ziyaret etmesini sağlamalıdır. Bunu takiben ziyaret eden kullanıcının sisteminde istenilen komut başarıyla çalıştırılabilir. XSS saldırılarda en büyük ortak amaç hedefin (kurban) çerezini (cookie) elde etmektir. Çerez (cookie) web sunucusunun kullanıcıyı tanılaması için kullandığı göstergedir. Hedef kullanıcının çerezini ele geçirmiş olan saldırgan web sunucu üzerinde erişim sağlayabilir, saldırılar yapabilir.

Bu tür saldırılar için kullanılan bir başka yöntem ise zararlı kodları forum sayfaları, kullanıcı isimleri, yorumlar, dosya adları gibi veritabanı, uygulama içerisinde saklanan alanlara yerleştirmektir. Siteler arası komut çalıştırma saldırılarının bu tip versiyonlarına Saklanmış Siteler Arası Komut Çalıştırma (Stored XSS) adı verilmektedir.

Ayrıca “<“ ve “>” gibi HTML etiketlerinde önemli olan karakterler kullanılmadan da XSS yapmak mümkündür.

Siteler arası komut çalıştırma saldırıları genellikle hedef olan kişinin web tarayıcısındaki güvenlik açıkları ve çalıştırılan kodun içeriği ile sağlanır. Bu nedenle uygulamalara sağlanan girdi parametreleri kontrol edilmeden kullanılmamalıdır.

Genel bir kural olarak, kullanıcı tarafından sağlanan girdiler incelenmeli, girdinin geçerliliği bir kural karşısında kontrol edilmeli ve uygun olmayan parametreler filtre edilmelidir.

Tercihen engelleme türü olarak “Beyaz Liste” yaklaşımı kullanılmalı, izin verilen karakterlerin dışındaki tüm karakterler engellenmelidir.

Çerezlerin (Cookie) HTTPOnly Olarak İşaretlenmemesi Açığı

Çerezler (Cookies), istemci tarafında web uygulamasıyla ilgili herhangi bir bilgiyi, oturum numarasını vs. saklamaya yarayan ve sadece kendisinin yollandığı alan adı (domain) için bilgilerini veren bir araçtır.  XSS (Cross Site Scripting) kısaca, HTML ve JavaScript yardımıyla bir sitede, siteye giren kullanıcıya tehlike arz edecek şekilde kod çalıştırmaya denir.

XSS açıklarından yararlanan kötü niyetli kişiler, JavaScript'in çerezleri yönetmeyi sağlayan özelliğinden yararlanarak sayfayı gezen kullanıcının çerez bilgilerini alıp, sisteme o ziyaretçiymiş gibi girebilirler. HttpOnly olarak işaretlenen çerezlere tarayıcı, javascript komutlarıyla erişemez. Bu da çerezleri XSS saldırısına karşı korumaktadır. HTTP başlıklarındaki Set-Cookie özelliğine HttpOnly deyimi eklenmelidir. Bu şekilde destekleyen tarayıcılar, HttpOnly deyiminin geçtiği çerezi JavaScript yoluyla alamayacaktır.

Ayrıca XSS saldırılarını engellemek için kullanıcı tarafından gelen bilgilerin filtrelenmesi de önemlidir. Çerez çalmak için gerekli olan kodun çalıştırılması için, öncelikle <script></script> etiketleri arasına yazılması gerekir ki, buradan  “<“ ve “>” karakterlerini filtrelenmesi alınabilecek diğer bir önlemdir.

Blind SQL Injection Açığı

SQL Injection, Web sayfalarına gönderilen girdilere SQL sorgu/komutları enjekte etme taktiğidir. Çoğu web uygulaması web kullanıcısından parametreler alır ve veritabanına SQL sorguları yapar. Örneğin, bir kullanıcı login olurken, web sayfası kullanıcının girdiği kullanıcı adı ve şifreyi alarak geçerli olup olmadığını kontrol için SQL veritabanına sorgular. SQL Injection ile, özel hazırlanmış bir kullanıcı adı ve/veya şifre alanı ile SQL sorgusunda değişiklik yaparak farklı sonuçlar elde edebilir.

Blind SQL Injection, SQL Injection için gereken SQL cümleciğinin deneme yanılma yoluyla bulunması yöntemine dayanır. Sunucu üzerinde koşan SQL cümleciğinin tamamı bilinemediği zaman veya bazı özel karakterler için filtreleme aşılması gerektiği durumlarda saldırganlar Blind SQL Injection yöntemiyle yüzlerce veya binlerce SQL sorgusunu deneyerek sonuçlar almayı hedeflerler.

Blind SQL Injection yapılabilecek alanlar, deneme yanılma yoluyla anlamlı bir SQL cümleciği oluşturan saldırganın sistem veya veritabanına yetkisiz erişim sağlamasıyla sonuçlanabilir.

Sql injection açığından korunmak için temel anlamda aşağıdaki adımların uygulanması gerekmektedir.

  • GET ya da POST ile yollanan verileri doğrulamak

  • Gönderilen verileri filtrelemek

  • SQL Hazır komutlarını kullanmak (Stored Procedure)

  • Kullanıcı yetkilerini kısıtlamak

  • Güvenliği test etmek, gözden geçirmek, önemli verileri encrypt etmek

Kullanıcı IP’sinden Bağımsız Oturum Oluşturma Açığı

Kullanıcı oturumunun kritik olduğu uygulamalarda kullanıcıların sisteme girmesi ile oluşturulan oturumlar sunucu ve kullanıcıda bulunan oturum kimliği (Session ID), kullanıcıda tutulan çerez (cookie) aracılığıyla kontrol edildiği gibi sunucu tarafında her oturumun ilgili kullanıcının IP numarası ile de ilişkilendirilmelidir.

Bu ilişkilendirilmenin yapılmaması halinde herhangi kullanıcının oturum kimliğini ve çerez dosyasını uzaktan ele geçiren bir saldırgan, kullanıcının oturumu üzerinden herhangi bir işlem gerçekleştirebilir.

Özellikle, kullanıcı girişi sayfalarında, ayrı bir kimlik doğrulaması yapılmaması durumunda, açılmış oturumu ele geçiren birisi, o kullanıcı üzerinden istediği işlemleri yetkisiz gerçekleştirebilir.

Kullanıcı oturum kimliği (Session ID), çerez (cookie) ve oturum kimliklerinin kullanıcı IP’leri eşlenerek tutulması, aynı oturum kimliği ile farklı IP’lerden oturuma erişimin engellenmesi gereklidir.

SSL Desteği Olmayan Kullanıcı Girişi Sayfaları

Kullanıcı adı, parola, kullanıcı kimlik bilgiler, kredi kartı gibi bilgilerin güvenliğini sağlamak için, böyle bilgilerin ağ üzerinden aktarılması sırasında şifrelenmesi gereklidir. Bu şifreleme, gerektiği durumlarda HTTP yerine, HTTPS yönteminin kullanılması ile sağlanabilir.

HTTP kullanılarak kullanıcı bilgilerinin aktarılması durumunda, kullanıcı bilgisayarı ile sunucu arasındaki ağ üzerinde herhangi bir yerde yapılacak dinleme bu bilgilerin başkasının eline geçmesi sonucunu doğuracaktır. Sistem tasarımındaki kullanılabilirlik dengesi göz önünde bulundurularak, bu yayının HTTPS üzerinden yapılması önerilir.

Form Girdisi Hatırlama Özelliği

Form kullanılarak kayıt yapılan uygulamalarda form girdisi hatırlama özelliği ile form girdileri bilgisayara kaydedilmektedir. Bu özellik aktif olduğu zaman, kullanıcı sisteme giriş yaptığında daha önce forma girdiği bilgiler, kullanmış olduğu web tarayıcısına kaydedebilir. Bu durumda kullanıcı bilgisayarının izinsiz kullanımı veya kullanıcının başka bir bilgisayardan giriş yapması durumunda kullanıcı seviyesinde veri gizliliği bozulmuş olur.

Form girdisi hatırlama özelliği aktif olan sayfalar üzerinde, Form bileşenlerinin girişlerindeki hatırlama özelliği kapatılmalıdır.

(<input type="text" name=“girdi" autocomplete="off" />)

Oturum açma sistemlerinde güvenliğin sağlanması sadece teknik olarak uygulama tasarımı güvenliğinden geçmemektedir. Güvenlik olgusu birçok küçük parçanın bir araya getirdiği büyük bir resim, halkalardan oluşan bir zincir gibidir.

Teknik olarak hiçbir açığın bulunmadığı bir uygulamada mantıksal tasarım nedeniyle oluşan açıklar otomatik tarama yazılımlarıyla tespit edilemez. Oturum açma sistemlerindeki güvenliğin denetlenmesi için manuel yöntemler ve konusuna hakim uzman görüşleri gereklidir.

 Referanslar

1- http://www.sans.org/reading_room/whitepapers/protocols/understanding-security-osi-model_377  

2- http://www.acunetix.com/websitesecurity/webserver-security.htm

3- http://insanesecurity.info/blog/8-tips-for-a-secure-login-scriptadmin-panel

4- http://cwe.mitre.org/data/definitions/614.html


Favori olarak ekle (0) | Görüntüleme sayısı: 8651

Bu yazıya ilk yorumu yazın

Sadece kayıtlı kullanıcılar yorum yazabilir.
Lütfen sisteme giriş yapın veya kayıt olun.

 
spacer.png, 0 kB
spacer.png, 0 kB
Copyright 2017 TÜBİTAK-BİLGEM. Sitenin teknik altyapısında Joomla kullanılmıştır. Yazar ve site referans gösterilmeden alıntı yapılamaz. Görüşleriniz
spacer.png, 0 kB