Oturum Yönetim Araçlarının Belirlenmesi: Çoğu web sunucu otomatik olarak oturum cookie’si yaratmakla birlikte tüm uygulamalar bunları oturum yönetimi amacıyla kullanmazlar. Oturum yönetimiyle ilgili testlere başlamadan önce yapılması gereken ilk iş oturum yönetim yöntemi ve kullanılan parametrelerin anlaşılmasıdır. Bu nedenle aşağıdaki denetim prosedürleri uygulanmalıdır:
- Cookie, URL parametreleri, hidden saha bilgileri gibi oturum yönetimi için kullanılabilecek tüm veriler belirlenmelidir. Bazen bunlardan bazıları bir arada kullanılabilir. Özellikle kullanıcı tanılamadan sonra istemci tarafına gönderilen yeni veriler dikkatle incelenmelidir. Sıklıkla (ki bu iyi bir uygulamadır) kullanıcı tanılamadan sonra yeni oturum token’ları üretilir.
- Hangi verilerin oturum yönetimi için kullanıldığını anlamak için oturum bağımlı bir sayfa için parametreler tek tek değiştirilmeli, varsa aralarında ilişki bulunan parametreler de tespit edilmelidir.
- HTTP Authentication (basic, digest, NTLM, vd.): Bu yöntemin kullanılması durumunda tarayıcı HTTP başlıklarını kullanarak kullanıcı tanılama sistemi ile iletişim kurar. Tarayıcı tanılama credential’larını her istekte gönderdiğinden bu durum her sayfada bir kullanıcı tanılama formu olması ve kullanıcının her seferinde credential’larını bu forma girerek göndermesine benzer. Ancak bu yöntem internet uygulamalarında pek kullanılmaz.
- Oturumsuz Durum Mekanizmaları (Sessionless State Mechanisms): Bu yöntem ASP.NET ViewState hidden form değişkeni gibi herhangi bir istemci verisine durumla ilgili tüm verileri yerleştirmek ve sonraki isteklerde talep etmekten ibarettir. Tabi verinin güvenliğini sağlamak için veriyi kriptolamak, binary hale çevirmek, bütünlüğünü korumak için anahtarlı hash değerini üretip mesaja eklemek gibi önlemleri almak gereklidir. Bu yöntemi kullanan uygulamalar verinin içine expiration date bilgisi de koyarak oturum yönetimindeki zaman aşımı ihtiyacını giderebilirler. Bu tür veriler uzunlukları, kriptolanmış veya verinin sonuna hash verisi eklenmiş görüntüleri, farklı isteklerde aynı veri kullanılması durumunda hata yaratmaları, her istekte bu verinin içeriğinin değişmesi gibi özelliklerinden ayrıştırılabilirler.
Kullanıcı tanılamadan sonraki aşamalarda sadece oturum token’ına güvenileceği için bu token’ın güvenliği çok önem kazanmaktadır. Oturum yönetim mekanizmalarıyla ilgili 2 temel açıklık alanı şunlardır:
- Oturum token’larının üretimindeki açıklıklar
- Oturum token’ının oturum yaşam döngüsü boyunca kullanım, iletim ve saklanmasında yaşanan açıklıklar
Oturum Token Üretiminde Ortaya Çıkan Açıklıklar
Oturum yönetiminde üretilen token’lar tahmin edilebilir olduklarında diğer kullanıcılara ait token’lar tahmin edilebilmekte, dolayısıyla onlara ait oturumlar çalınabilmektedir.Anlamlı Token’lar: Eğer token’lar içinde kullanıcı kodu veya Id’si, kullanıcının gerçek ismi ve/veya soyadı, e-posta adresi, bağlanılan IP adresi, tarih ve saat, sıralı artan ve tahmin edilebilen bir sayaç gibi anlamlı bilgiler varsa diğer kullanıcıların token’larını tahmin etmek de kolaylaşacaktır.
Denetim adımları olarak aşağıdaki prosedür izlenebilir:
- Öncelikle gelen token bir şekilde obfuscate edilmişse, bunu çeşitli yöntemlerle decode etmeye çalışmak lazımdır. Bu yöntemlere örnek olarak XOR, Base64 decoding, hex değerleri Ascii değerlere çevirme verilebilir.
- Orjinal token veya decode edilmiş token içinde anlamsız görünen binary bilgiler pad’leme amacıyla üretilmiş, bu nedenle de oturum yönetiminde önemsiz olabilir. Bu gibi bilgileri ve token’ın diğer bölümlerini oturum yönetimi açısından gerekliliklerini test etmek için byte-byte veya bit-bit değiştirerek tekrar gönderip oturum yönetiminde hata alınıp alınmadığı test edilmelidir. Bu sayede daha sonraki testlerde token’ın odaklanılacak alanı daraltılıp daha etkin testler yapılabilir.
- Farklı kullanıcılar olarak bağlanarak token örnekleri toplanmalıdır. Eğer kendi kayıt yapma imkanı varsa benzer kullanıcı isimleri için (örneğin “AA”, “AAA”, “AAAA” gibi) deneme yaparak oluşan token’lar incelenebilir. Farklı IP adreslerinden yapılan bağlantılar da token’ın içeriğine etki ediyorlar mı diye denenebilir.
- Token’larda kullanıcı adı ve diğer kullanıcı tarafından etkilenebilen bilgiler bulunup bulunmadığı araştırılmalıdır.
- Edinilen bilgiler kullanılarak farklı kullanıcıların oturum token’ları tahmin edilmeye çalışılmalıdır.
Tahmin Edilebilir Token’lar: Anlamlı bilgiler içermese de token’lar tahmin edilebilir şekilde üretiliyorsa (örneğin belli kısımları sabit, belli kısımları sabit katsayılarla artıyorsa) yine başka kullanıcıların token’larını tahmin etmek mümkün olabilir. Token’ları bu açıdan incelemek için aşağıdaki denetim prosedürü uygulanabilir:
- Token’ların ilk olarak üretildiği istekler bulunmalıdır. Bazı uygulamalar ilk istekle ürettiği token’ı tüm oturum boyunca kullanır, bazı uygulamalar login aşamasında oturumun kalanı için kullanacağı token’ı üretir. Token’ın ilk defa üretildiği isteği kısa bir zaman aralığında çok sayıda göndererek mümkün olduğunca fazla token örneği üretilmelidir. Bu şekilde zaman farkından ve araya giren diğer kullanıcılardan kaynaklı farklılaşmalar minimuma indirilebilir.
- Elde edilen token’lar arasında bir pattern olup olmadığı araştırılmalıdır. Webscarab’ın böyle bir aracı bulunmaktadır. Ancak eğer bir obfuscation kullanılıyorsa bu araç doğru sonuçları üretemeyebilir.
- Çoğu durumda manuel analiz gerekecektir. Bunun için aşağıdaki işlemler uygulanabilir:
- Daha önceden token’ın hangi bölümlerinin gereksiz olabileceğine dair yapılan test sonuçları kullanılarak token’ın üzerinde çalışılacak alanı daraltılmalıdır. İstekler arasında değiştirilse bile oturum yönetiminde dikkate alınmayan bölümler göz ardı edilmelidir.
- Token üzerinde veya bir kısmında eğer bir obfuscation var gibi görünüyorsa daha önce bahsedilen decoding teknikleri denenmelidir.
- Token’ın artan bölümleri ardışık mı artıyor ve hangi katsayıyla artıyor araştırılmalıdır.
- Birkaç dakika beklendikten sonra yeniden token örnekleri toplanmalıdır. Bu şekilde zamanla yakından ilgili alanlar belirlenmelidir.
- Bazen farklı kullanıcı kodları veya IP adreslerinden yapılan istekler sonucu üretilen token’lar bu bilgilerin entropi yaratılma amacıyla kullanılmasından dolayı çok farklı yapılarda olabilirler. Bu durumda bir perspektiften (kullanıcı kodu, IP adresi, kullanıcı grubu, vs.) elde edilen token’lardan yola çıkarak diğerleri extrapolate edilemeyebilir. Bu açılardan farklı kullanıcı kodu ve IP’ler kullanılarak da token örnekleri toplanmalı ve incelenmelidir.
- Eğer tahmin için yeterince bilgi sahibi olunduğu düşünülüyorsa başka kullanıcıların token’larını tahmin etmek için kaba kuvvet saldırısı düzenlenebilir.
- Eğer denetlenen uygulamanın kaynak kodu ele geçirilebilmişse uygulama içinde token’ı üreten algoritma incelenerek token tahmini yapılmaya çalışılabilir.
Token üretimi ve bunların tahmin edilememesi güvenlik açısından son derece önemli olmakla birlikte token’ların yaşam süresi boyunca iletildiği ve saklandığı ortamlardaki güvenliği de en az o kadar önemlidir.
Token’ların Ağ Üzerinde Açık Olarak Gönderilmesi: HTTP bilindiği üzere metin tabanlı ve açık bir protokoldür. Bu nedenle HTTPS kullanılsa bile MITM yapılarak HTTP trafiği izlenebildiğinde içeriğinde bulunan oturum token’ları da görülebilir. Token’ların ağ üzerinde izlenmesine yol açabilecek durumlardan bazıları aşağıdaki gibidir:
- Bazı uygulamalar kullanıcı tanılama aşamasında HTTPS kullanmakta ancak tanılamadan sonra HTTP iletişimine geçmektedir. Dolayısı ile HTTP iletişimi sırasında dinleme yapılabiliyorsa oturum çalınabilir.
- Bazı uygulamalar kullanıcı tanılama yapılmadan HTTP protokolü ile anonim olarak ziyaret edilebilen sayfalar için ilk istek sırasında ürettiği token’ı daha sonra tanılama yaptıktan sonra da kullanmaya devam etmektedir.
- Uygulama kullanıcı tanılama sırasında yeni bir token üretse ve o andan sonraki iletişimi HTTPS üzerinden yapsa da eğer tanılama öncesi sayfalara linkleri izleyerek, geri tuşuna basarak veya URL’i tekrar yazarak tekrar ulaşırsa (Yardım veya İletişim Bilgileri gibi) token’ı açıkta gönderilecektir.
- Uygulama HTTPS ile kullanıcı tanılama yapsa da bu fonksiyon HTTP ile de ulaşılıyorsa, araya giren bir saldırgan “login” linkini HTTP linki olarak değiştirirse tanılamadan sonra yeni bir token üretilse de izlenebilecektir.
- Bazı uygulamalar tüm statik içerik için (resimler, betikler, style sheet’ler, sayfa şablonları, vs.) HTTP kullanmaktadır. HTTPS ile erişilse de uygulama bu kaynaklara HTTP ile ulaşacağından ve bu iletişimde de cookie’leri göndereceğinden izlenme riski vardır. Tarayıcıların çoğu bu durumda şu tür bir mesaj vererek kullanıcıları uyarmaktadır: “This page contains both secure and nonsecure items. Do you want to display the nonsecure items?”
- Başlangıç URL’inden başlayarak uygulamanın tüm safhaları geçilirken gönderilen oturum cookie’leri, HTTPS ve HTTP arasındaki geçişler izlenmelidir. Bu Wireshark gibi bir ağ dinleme cihazıyla ve/veya belli oranda da bir proxy aracıyla yapılabilir.
- Cookie’ler kullanılıyorsa HTTPS bağlantılarının dışında gönderilmelerini engellemek için “secure” özelliklerinin bulunduğundan emin olunmalıdır.
- Uygulamanın normal kullanımında kriptolanmamış herhangibir bağlantı kurulup kurulmadığı izlenmelidir. Eğer kuruluyorsa bu durum oturum bilgilerinin gizliliği açısından zafiyet yaratabilir.
- Eğer uygulama HTTP ile başlıyor ve login’le birlikte HTTPS’e geçiyorsa oturum yönetimi için başta üretilen bir cookie’nin mi, yoksa HTTPS’le birlikte üretilen yeni cookie’nin mi kullanıldığı kontrol edilmelidir. Ayrıca uygulamanın HTTP ile login’i kabul edip etmediği de URL değiştirilerek denenmelidir.
- Uygulama tamamen HTTPS kullanıyor olsa bile sunucunun 80 portu da kontrol edilmelidir. Eğer port açıksa authenticate olunmuş bir oturumdan doğrudan HTTP ile bir URL’e ulaşmaya çalışılmalı ve oturum bilgilerinin iletilip iletilmedikleri kontrol edilmelidir. Eğer bir token HTTP ile iletiliyorsa sunucunun bu token’ı iptal edip etmediği test edilmelidir.
- Kullanıcının tarayıcı log’ları
- Web sunucu log’ları
- Kullanıcı’nın bulunduğu kurumun veya ISP’nin proxy log’ları
- Uygulamayı host eden kurumun reverse proxy log’ları
- Kullanıcı’nın ziyaret ettiği başka bir uygulamanın “Referer” log’ları
Bu konuyla ilgili denetim prosedürü olarak aşağıdaki adımlar izlenebilir:
- Uygulama kullanımı sırasında URL içinde bir URL token’ı gönderilip gönderilmediği izlenmelidir. Uygulama genelde bu yöntemi kullanmasa da uygulama geliştiriciler bazen bu yönteme başvururlar. Bu durumlara örnek olarak uygulamanın farklı bir uygulamaya istek göndermesi veya redirect URL’leri verilebilir.
- Eğer on-site denetim yapıyorsanız uygulamanın log’lama kabiliyeti, loglarda tutulan bilgiler, bu loglara kimlerin erişebildiği gözden geçirilmelidir. Uzaktan denetimde de gizli içeriğin araştırılması sırasında log’lara ulaşılabiliyorsa bu bilginin ciddi zafiyet yaratabileceği not edilmelidir.
- Eğer uygulama mesaj bırakma fonksiyonuna sahipse, yani başka kullanıcıların görebileceği mesajlar bırakılabiliyorsa kendi kontrol ettiğiniz bir web sunucusuna ait bir link bırakın. Daha sonra sunucunuza gelen isteklerdeki Referer bilgilerini token bilgisi barındırıp barındırmadığını tespit için kontrol edin. Eğer token ele geçirebiliyorsanız bu kullanıcıların oturumlarını kendi oturum token’ınızı değiştirerek çalmaya çalışın.
Token’larla Oturumların İlişkilendirilmesindeki Açıklıklar: Bazı uygulamalar oturum yönetiminin anlamını güvenlik ihtiyaçlarını gidermekten ziyade beni hatırla türü bir fonksiyon olarak yorumlarlar. Örneğin kullanıcıya her login olduğunda veya kullanıcı birden fazla tarayıcıdan veya bilgisayardan uygulamaya eriştiğinde aynı token’ı vermek güvenlik açısından olumlu değildir. Bu yaklaşımın fonksiyonellik adına da getirdiği fazla bir artı yoktur, tam aksine işlem bütünlüğünü dahi tehdit edebilir.
Token / Oturum ilişkilendirmesinde ortaya çıkabilecek başka bir açıklık da Token’ın belli bölümü’nün kullanıcıyla ilişkilendirilirken kalan bölümünün uygulama tarafından geçerli kabul edilebilecek herhangi bir değişken olmasıdır. Örneğin token’ın içinde kullanıcı kodu ve “R1” adında başka bir değişken bulunması durumunda uygulama geçerli herhangi bir kullanıcı kodunu kabul edip erişim kontrolünü bu bilgiye göre yapıyor ve herhangi bir geçerli R1 değerini kabul ediyorsa başka bir kullanıcının oturumunu çalmak mümkündür.
İlişkilendirme açıklarının denetlenmesi için aşağıdaki prosedür izlenebilir:
- Uygulamaya aynı kullanıcı koduyla farklı tarayıcılar veya bilgisayarlardan girilir. Her iki oturumunda aynı anda geçerli olup olmadığı kontrol edilmelidir. Eğer gerçek bir iş ihtiyacı yoksa bu fonksiyonalite güvenlik açısından anlamsızdır.
- Aynı kullanıcı kodunu kullanılarak birkaç defa login ve logout olun. Her defasında aynı token’ın atanıp atanmadığını kontrol edin.
- Eğer token anlamlı bilgiler içeriyorsa, kullanıcı kimliğine ilişkin alanları geçerli başka bir kullanıcınınkilerle değiştirin. Eğer uygulama bu kullanıcı bağlamında çalışmaya devam ediyorsa ciddi bir zafiyet barındırıyor demektir.
Oturum Kapanış Açıklıkları: Oturumların uzun süreler geçerli kalması saldırganların başarılı olma ihtimalini artıracaktır. Örneğin kaba kuvvet saldırılarının iptal edilmeyen oturumları tespit etme, loglardan, ağı izleyerek veya MITM saldırılarıyla ele geçirilen token’ların yeniden kullanılma ihtimalleri artacaktır.
Ayrıca kullanıcılara kendi inisiyatifleriyle logout olma fonksiyonalitesi sağlanmalıdır. Oturumun sonlandırması sunucu tarafında yapılmalıdır. Bazı uygulamalar logout fonksiyonalitesi olarak kullanıcı tarayıcısına Set-Cookie komutuyla cookie’yi boşaltma talimatı göndermekte böylece kullanıcı güvenli bir sayfaya ulaşmak istediğinde login sayfasına yönlendirilmektedir. Ancak eski cookie değeriyle sunucuya erişmek hala mümkündür. Bazı uygulamalar logout fonksiyonalitesi için sunucuya istek dahi göndermez ve istemci tarafında bir betikle cookie’nin içeriği boşaltılır. Ancak gerçekte oturum hala sonlandırılmamıştır.
Bu açıklıklara karşı izlenebilecek denetim prosedürü aşağıdaki gibidir:
- Uygulamaya login olarak bir token alın, belli bir süre bekledikten sonra güvenli bir sayfaya erişmeye çalışın. Eğer ulaşabiliyorsanız oturumunuz hala aktif demektir. Uygulamanın oturum timeout zamanını belirlemek için Burp Intruder her seferinde artan zaman aralığıyla istek gönderme fonksiyonalitesini desteklemektedir.
- Uygulamanın logout fonksiyonalitesinin olup olmadığı denetlenir. Logout fonksiyonalitesinin olmaması kullanıcıların özellikle ortak kullanılan bilgisayarlarda daha yüksek risk altında olmasına neden olabilir.
- Logout fonksiyonu varsa etkinliği test etmek için token bilgisini kaydederek logout olunur. Daha sonra aynı token kullanılarak güvenli sayfalara ulaşılmaya çalışılır.
Kullanıcı’dan Token Çalınma Açıklıkları: Kullanıcı token’ına ulaşmak veya kullanıcı token’ını kullanarak saldırı gerçekleştirmek için çeşitli yöntemler bulunmaktadır, örneğin:
- En bilinen token çalma saldırısı XSS saldırısıyla kullanıcının cookie’sini çalarak istenen bir sunucuya gönderme yöntemidir.
- Kullanıcı token’ından faydalanarak bazı işlemleri gerçekleştirmenin yöntemlerinden biri de Session Fixation saldırısıdır. Bu saldırı genel olarak saldırganın uygulamanın login olunması gerekmeyen bir sayfasına erişerek geçerli anonim bir token alması, daha sonra hedef kullanıcıyı bu token’ın bulunduğu bir URL’e tıklayarak (oturum token’ının URL’de olması durumunda) veya bir XSS açığından faydalanarak kullanıcı token’ını belirleyerek (token’ın cookie olması durumunda) uygulamaya ulaşması, daha sonra login olduğunda saldırganın hedefin oturumunu çalması şeklinde gerçekleşir. Tabi bu saldırının başarılı olabilmesi için uygulamanın login olduktan sonra da anonim token’ı kullanmaya devam etmesi gerekmektedir.
- Hedef uygulamada bulunan XSS açıklıkları tespit edilir ve bunların diğer kullanıcıların oturum token’larını çalmak için kullanılıp kullanılamayacağı test edilir
- Uygulama tanılanmamış kullanıcılara oturum token’ı üretiyorsa ve uygulamaya login olunduğunda yeni bir token üretilmiyorsa bu uygulama session fixation saldırısına açıktır.
- Uygulama anonim kullanıcılara token üretmiyorsa bile login olunarak token alınır ve tekrar login sayfasına ulaşılmaya çalışılır. Eğer login sayfasına ulaşılarak aynı token ile başka bir kullanıcı olarak login olunabiliyorsa uygulama session fixation saldırısına açıktır.
- Uygulamanın ürettiği token’ların formatı incelenir ve geçerli olabilecek bir token yaratılıp yaratılamayacağı araştırılır. Eğer böyle bir token üretilebiliyor ve bu token’la uygulamaya erişilebiliyorsa uygulama session fixation saldırısına açıktır.
- Uygulama login fonksiyonalitesine sahip olmasa da hassas kişisel bilgi işliyorsa (örneğin kişisel ve ödeme bilgileri) ve bunlar gönderildikten sonra görüntüleme fonksiyonalitesi varsa (örneğin view my order sayfasından) yukarıdaki 3 test session fixation açıklıklarına karşı denetlenmelidir.
Cookie Scope’unun Gereğinden Liberal Tanımlanması
Cookie Domain Kısıtlaması: Genellikle cookie’ler sunucular tarafından Set-Cookie başlığıyla tanımlanıp tarayıcı tarafından ilgili sunucuya yapılan her talepte Cookie başlığıyla geri gönderilir. Ancak cookie işleyişi bununla sınırlı değildir. Set-Cookie başlığı içinde cookie için bir “domain” özelliği de tanımlanabilir. Normal kullanımda cookie sunucunun alan adı ve bunun altında bulunan subdomain’lere gönderilir. Örneğin cookie’yi gönderen sunucu www.abc.com ise cookie bu alan adı ve alt alan adlarına (persistent cookie değilse o tarayıcıdan) yapılan (örneğin “alt.www.abc.com” sunucusuna) isteklerde gönderilecektir
Domain özelliği ile en üst seviye (top level) alan adları (.com, .org, .tr gibi) olmamak kaydıyla sunucunun üst (parent) alan adları tanımlanarak cookie’nin scope’u genişletilebilir. Örneğin normalde www.abc.com tarafından gönderilen bir cookie “zzz.abc.com” sunucusuna yapılan bir istekle gönderilmeyecekken “domain=abc.com” özelliği tanımlanmışsa artık bu sunucu ve “abc.com” alan adının altında bulunan diğer sunuculara da belirlenen cookie gönderilecektir.
Cookie Dizin Kısıtlaması: Tarayıcı öntanımlı olarak cookie’yi onu tanımlayan sayfanın altında bulunduğu dizin ve onun alt dizinlerine yapılacak isteklerde gönderir. Örneğin “/apps/secure/my-app/index.jsp” tarafından tanımlanan cookie “my-app” ve bunun altındaki dizinlere yapılan isteklerde gönderilir. Domain kısıtlamasına benzer şekilde cookie’nin gönderilebileceği dizinler ilgili dizinin üst dizinleri olacak biçimde genişletilebilir. Örneğin cookie için “path=/apps/” özelliği tanımlandığında bu dizin ve altındaki dizinlerde bulunan kaynaklara yapılan isteklerde de cookie gönderilecektir. İlk bakışta bir sakınca yokmuş gibi görünse de üst dizinlerde güvenlik ihtiyaçları daha düşük bir uygulama bulunması ve bu uygulama nedeniyle cookie bilgisi sızabilirse (loglarını gören kişilerin güvenlik bilincinin olmaması, geliştiren kişilerin yetersiz veya kötü niyetli olması gibi) risk oluşabilir.
Bu açıklıklarla ilgili izlenebilecek denetim prosedürü aşağıdaki adımlardan oluşabilir:
- Uygulamanın gönderdiği tüm cookie’ler “domain” ve “path” özellikleri için incelenmelidir. Eğer bu özellikler tanımlı ise oluşabilecek riskler açıklanmalıdır.
