Merhaba
Web uygulamaları, kullanıcı adı ve parola doğrulamasını başarılı bir şekilde tamamlamış kullanıcıları tanıyabilmek adına Session adını verdiğimiz değerleri kullanmaktadır. Bu değer, kullanıcının oturum bilgilerini doğru girmesi durumunda sunucu tarafından, tahmin edilmesi imkansız olan bir anahtar (teoride) üretilerek kullanıcıya Cookie bilgisi iletilmektedir. Bu aşamadan sonra kullanıcının internet tarayıcı kendisine sunucu tarafından iletilen bu Cookie değerini, üreteceği her HTTP talebine ekler ve böylece uygulamaya kendisini tanıtmış olur.
Burada ki en ciddi problem, sunucu tarafından kullanıcıya tahsis edilmiş, eşsiz ve tahmin edilebilirliği teoride imkansız olan bu anahtarın 3. bir şahsın eline geçtiği anda yaşanmaktadır. Oturum mekanizması olmayan HTTP protokolünün bu tür durumları tespit etme özelliği yoktur. Bu nedenle eğer uygulama tarafından “eş zamanlı olarak aynı kullanıcının farklı ip’ler ile erişim gerçekleştirmesi yasaktır.” gibi bir iş kuralı uygulanmadıysa, web uygulaması için saldırgan da gerçek kullanıcı da aynı kişidir!
Peki session bilgisi hangi saldırılar ile 3. şahısların eline geçebilir ?
- Network trafiği dinlenerek.
- XSS zafiyetlerinin sömürülmesi ile.
- Oturum sabitleme ( Session Fixation, dolaylı yoldan bu konu ile alakalıdır. )
- Zararlı yazılım ile.
- Fiziksel erişim.
İlk akla gelen bu 4 farklı saldırı yönteminin de başarısız olduğu durumlar olabilir. Bu noktada, 6. madde diyebileceğimiz “Session Prediction” saldırısı gerçekleştirilebilir. Özetle; Kullanıcılar ile etkileşime geçmeden, geçerli bir oturum anahtarı tahmin etmek.
Session Randomness
Kullanıcıya web uygulaması tarafından tahsis edilmiş oturum anahtarının tahmin edilebilirliğini zorlaştırmak, uygulama tarafından üretilen anahtarın rastgeleliği ile doğru orantılıdır. Bu nedenle uygulama tarafından üretilen oturum anahtarlarının (yani session id ) rastgeleliği penetration testerlar tarafından ele alınan bir konudur.
Bizde analizimizi, aşina olduğumuz PHPSESSID üzerinde gerçekleştireceğiz. Web uygulaması olarakta zafiyet barındıran DVWA uygulaması tercih edilebilir. Bu testi, vazgeçilmez güvenlik testi araçlarından birisi olan Burp Suite ile gerçekleştireceğiz.
Her zaman ki gibi Firefox’a proxy ayarlarını yapıp Burp Suite’i çalıştırarak başlıyoruz. Web uygulaması, PHPSESSID değerini gönderdiğiniz ilk HTTP talebinde oluşturacak ve Set-Cookie ile size gönderecektir. İlk talebi capture edip, sağ tıklayıp Send to Sequencer diyerek Burp Suite sequencer modülüne gönderiniz.
Ardından Sequencer size Token Location Within Response sekmesinde, test etmek istediğiniz token değerinin geçtiği alanı soracaktır. Default olarak Cookie bilgisini ve talep için sunucu tarafından üretilen html içerikteki formları analiz ederek opsiyonlar çıkacaktır. Biz Cookie değerini doğrudan kullanabiliriz. CSRF Token’lar için Randomness testi gerçekleştirmek isterseniz Custom alanına form field’ını belirtebilirsiniz.
Ardından Start live capture butonuna bastığınızda Burp Suite, sequencer’a gönderdiğiniz HTTP talebini tekrar tekrar oluşturarak uygulamanın farklı PHPSESSID değerler üretmesini sağlayacaktır. Bunu yapmasının nedeni ise, randomness’i ölçebilmek adına belirli bir sayıda örneğe ihtiyaç duyuyor olmasıdır.
Yukarıdaki resimde görüldüğü üzere 436 adet token toplamış bulunmakta. Bu değer 20.000’e geldiğinde analizi yapması için Burp Suite’e komut vereceğiz.
FIPS monobit test
FIPS monobit test, her bit pozisyonunu 1 ve 0’a çevirerek dağılımlarını analiz etmektedir. Bu FIPS monobit testi için 20.000 adet sample toplamanız gerekiyor. Gerçekten random dağılım gösteren bir data setinin testinde 1 ve 0’ların sayısı yaklaşık olarak aynı olmalıdır.
Topladığımız 20.000 PHPSESSID örneğinin FIPS monobit analizi sonucu yukarıdaki gibidir. PHPSESSID üretim algoritmasının %0.01 olan FIPS pass level’i her bit pozisyonunda geçmeyi başardığını ve yaklaşık olarak eşit oranlarda 1 ve 0 içerdiğini görmekteyiz.