- HTML form tabanlı tanılama
- Çok faktörlü tanılama (örneğin password ve token’ın bir arada kullanılması gibi)
- İstemci SSL sertifikaları
- HTTP Basic ve Digest kullanıcı tanılama
- NTLM veya Kerberos ile Windows’a entegre kullanıcı tanılama
- Kullanıcı tanılama servisleri (örneğin Microsoft Passport)
Tasarım Hataları
Kötü Password’ler: Password’ler herkes tarafından bilindiği gibi sözlükte bulunmayan, kısa olmayan, anahtar genişliğini artırmak için farklı karakter gruplarını içeren, kullanıcı adıyla aynı olmayan şekilde seçilmelidir.Denetim prosedürü olarak uygulamanın password politikası öğrenilmeye çalışılmalı, kendi kendine kaydolmak mümkünse politikanın uygulanması test edilmelidir. Ayrıca password değiştirme imkanı varsa mevcut password zayıf bir password’le değiştirilmeye çalışılmalıdır.
Login Kaba Kuvvet Saldırısı: Daha önce açıklanan yöntemlerle (mesaj statü kodu, uzunluğu, içinde geçen kelimeler) uygulamanın başarılı ve başarısız login denemelerine verdiği tepkileri anlaşılmalıdır. Elde edilen kullanıcı kodları veya tahmin edilen kullanıcı kodlarına karşı sözlük saldırısıyla zayıf password’ler tahmin edilmelidir. Bu işlem için kendi geliştireceğiniz betikleri kullanabileceğiniz gibi Burp Intruder gibi bir saldırı proxy’si de kullanılabilir.
Tabi burada da tüm kaba kuvvet saldırıları gibi password politikasının kullanıcı hesaplarını kilitlemesine karşı dikkatli olmak gereklidir. Bazı uygulamalar hatalı login deneme sayısını istemciye gönderdikleri bir saklı alan veya cookie ile takip ederler. Bu değer istemci tarafında manipüle edilerek password kilitleme politikası safdışı edilebilir. Kaba kuvvet saldırısı yaparken password bazlı deneme yapmakta, yani aynı passwordü sırasıyla hedeflenen tüm kullanıcı kodları için kullanmakta fayda vardır. Bu şekilde zaman limitine göre hesap kilitleme politikasından kaçınılabilir ve ortak password kullanımı da tespit edilebilir.
Bilgilendirici Hata Mesajları: Login sırasında hata alındığında hangi faktörün hatalı olduğuna dair bilgi alınabiliyorsa (gerek açık biçimde gerekse dönen yanıttaki boyut veya içerikteki herhangibir değişiklikten yola çıkarak) kullanıcı kodu tespiti yapılabilir.
Bu test sadece ana login ekranında değil self-registration, password değiştirme, password resetleme gibi fonksiyonalite sağlayan ekranlarında da gerçekleştirilebilir.
Credential’ların Güvensiz İletimi: Kullanıcı kodu ve password gibi credential’lar kullanıcı bilgisayarında, ağ üzerinde, sunucularda, log kayıtlarında, yedeklerde ve başka yerlerde bulunabilir. Bu bilgilerin güvenliği sağlanarak (yani kriptolanarak ve replay saldırısına izin vermeyecek şekilde) iletilmesi (ve mutlaka gerekiyorsa saklanması) gereklidir.
Credential’ların iletildiği, varsa sunucu tarafından geri gönderildiği ve kullanıcı bilgisayarında saklandığı her durum tespit edilmelidir. Password gibi belli bir metni HTTP mesajları içinde saldırı proxy’si içinde otomatik olarak aramak mümkündür. Eğer credential’lar açıkta gönderiliyorsa bu ciddi bir zafiyettir. Obfuscate ediliyorlarsa orjinal metnin tahmininin mümkün olup olmadığı araştırılmalıdır.
Eğer credential’lar URL içinde gönderiliyorsa tutulan log’ların içinde görülebileceğinden çok sakıncalı bir durumdur. Bazı uygulamalar login sayfasına gönderilen mesajı 302 redirect’i ile başka bir URL’e yönlendirirken credential’ları URL içine yazabilirler. Bu durum pratikte yukarıdaki durumla aynı sonucu doğuracaktır.
Credential’lar “beni hatırla” veya başka fonksiyonaliteler için kullanıcı bilgisayarında kalıcı cookie’lerine kaydediliyorsa bunlar XSS gibi farklı saldırılara maruz kalabilirler.
Password Değişiklik Fonksiyonalitesi: Password değişiklik fonksiyonalitesi güvenlik açısından gereklidir. Ancak login sayfasının maruz kaldığı tehditlerle aynı tehditlere maruz kalabilir.
Denetim prosedürü olarak web uygulamasının açıkça link verilmemiş olsa bile password değiştirme sayfası bulunması olasılığına karşın araştırma yapılmalıdır. Password değişiklik sayfasında geçersiz kullanıcı kodu, geçersiz password, yeni password ve yeni password’ü doğrulama alanlarına farklı değerler girilerek uygulamanın davranışı izlenmelidir. Bu izleme sonrası farklı kullanıcı isimlerini belirlemek veya farklı kullanıcıların password’lerine yönelik kaba kuvvet saldırıları yapmak mümkün olabiliyorsa bu testler gerçekleştirilmelidir (Kaba Kuvvet Saldırısı ve Bilgilendirici Hata Mesajları bölümlerinde anlatıldığı gibi).
Unutulan Password (password reset) Fonksiyonalitesi: Password reset sayfaları genellikle kullanıcılara daha önceden belirledikleri bir soru sorarlar ve doğru yanıtlanması durumunda kullanıcının e-posta hesabına bir aktivasyon linki gönderirler.
Bu fonksiyonalite yine kullanıcı kodu belirlenmesi için kullanılabilir (doğru kullanıcı kodları ve hatalı kullanıcı kodları için gelen yanıtlardan yola çıkarak). Uygulama aktivasyon için bir URL linki üretiyorsa kendi kullanıcımız için bu linklerden çok sayıda ürettirerek tahmin edilebilir bir yapıda olup olmadıklarını test etmeliyiz. Uygulama gönderdiği linke tıklanması durumunda tanılanmış bir oturumu otomatik olarak başlatıyorsa URL linkinin tahmin edilebilmesi ciddi bir açıklık doğuracaktır.
Bazı uygulamalar sorulan challenge’a doğru cevap verilmesi durumunda hemen yeni password belirleme ekranını göstererek kullanıcının password’ünü değiştirmesini sağlayabilir. Bu şekilde hiç bir bilgilendirme mail’i almayan bir kullanıcı bir daha login oluncaya kadar hesabının ele geçirildiğini bilemeyecektir.
Başka kullanıcılar için gelen soruların seçilebilip seçilemediğini, çok kolay sorular içerip içermediklerini, eğer sorular rastgele seçiliyorsa arka arkaya password reset işlemini başlatarak istediğimiz soruya gelip gelmediğini denetlemek gereklidir.
Beni Hatırla Fonksiyonalitesi: Bazı uygulamalar kullanım kolaylığı sağlaması açısından bu fonksiyonaliteyi sağlarlar. Bu fonksiyonalite genellikle tasarım olarak güvensizdir ve kullanıcıyı hem lokal saldırılara hem de diğer kullanıcılar tarafından gerçekleştirilebilecek XSS saldırılarına açık hale getirirler.
Denetim prosedürü olarak uygulamanın böyle bir fonksiyonalitesi varsa “persistent cookie” olarak kullandığı değerin tahmin edilebilir olup olmadığı incelenmelidir. Eğer tahmin edilebiliyorsa (örneğin kullanıcı adıysa) tespit edilebilen herhangi bir kullanıcı olarak uygulamaya girilebilir.
Eğer obfuscated cookie değerleri kullanılıyorsa farklı kullanıcılar için ve/veya farklı zamanlarda bu özelliği geçerli hale getirerek içeriğinin tahmin edilip edilemeyeceği araştırılmalıdır. Bu offline bir analiz olabileceği gibi online olarak cookie içeriğindeki değişikliklere nasıl yanıt alındığının testini de içerebilir.
Eğer fonksiyonalite sadece kullanıcı adını hatırlama ve password’ü yine de sormayla kısıtlıysa daha güvenlidir. Ancak bu yöntem de tıpkı diğerleri gibi alınan hata mesajlarından yola çıkarak kullanıcı kodu tespitine imkan verebilir.
User Impersonation Fonksiyonalitesi: Call Center gibi organizasyonlarda web uygulamaları kullanılması durumunda call center görevlisinin müşterinin ürünlerini görebilmesi için onun kullanıcısını impersonate etme imkanı olabilir. Bu tür bir fonksiyonalite hem yatay hem de dikey kullanıcı hakkı ele geçirme saldırılarına tabi olabilir.
Denetim fonksiyonu olarak bu tür bir gizli fonksiyonalite olup olmadığı araştırılmalıdır (örneğin /admin/ImpersonateUser.jsp gibi). Bu fonksiyonalitenin nasıl çalıştığı diğer testlerde olduğu gibi incelenmeli, sistem yöneticisi ve diğer kullanıcıların impersonate edilip edilemedikleri test edilmelidir.
Bazen impersonation fonksiyonalitesi her kullanıcı için bir backdoor password kullanılarak sağlanabilir. Bunun için kaba kuvvet saldırıları sırasında birden fazla password’ün geçerli olduğu kullanıcıları gözden kaçırmamakta fayda vardır.
Uygulamanın tüm sayfalarında kendi kullanıcı kodunuzun herhangi bir parametre içinde gönderildiği sayfaları belirleyip bu bilgiyi manipüle ederek başka kullanıcıları impersonate edip edemeyeceğimiz tes edilmelidir.
Credential’ların Yetersiz Değerlendirilmesi: İyi bir tanılama sistemi daha önce bahsedilen belli password kriterlerini uygulamalı ve bunları kontrol etmelidir. Denetim prosedürü olarak password’ünüzün son karakterini değiştirme, harflerin büyüklük küçüklüğünü değiştirme yöntemleriyle kontrol mekanizması anlaşılmaya çalışılmalıdır.
Bu testin sonuçları kaba kuvvet saldırılarına da aktarılırsa bu saldırının etkinliği artırılabilir.
Tek Olmayan Kullanıcı İsimleri: Eğer uygulama kullanıcı kaydına izin veriyorsa aynı kullanıcı ismiyle birden fazla kullanıcı yaratılmasına izin verilip verilmediği kontrol edilmelidir. Eğer bu mümkün değilse bu özellik kullanıcı kodunun varlığını tespit etmek için kullanılabilir. Eğer mümkünse aynı kullanıcı kodu ve aynı password ile 2 kullanıcı yaratarak uygulamanın davranışı incelenmelidir.
Tahmin Edilebilir Kullanıcı Kodları: Uygulama kullanıcı kaydına izin veriyor ve kullanıcı kodlarını otomatik olarak üretiyorsa art arda kullanıcı kayıtları yaparak üretilen kullanıcı kodlarını incelemek gereklidir. Eğer kullanıcı kodları tahmin edilebilir bir yapıda üretiliyorsa daha önce kaydolmuş geçerli kullanıcılar tahmin edilebilir.
Tahmin Edilebilir İlk Password’ler: Eğer uygulama ilk password’leri otomatik olarak üretiyorsa birden fazla kullanıcı kaydı yaparak yakın zamanda kayıt yaptıran diğer kullanıcıların password’lerinin tahmin edilip edilemeyeceği denetlenmelidir. Password’ler kısmen benzerlik gösterseler bile kaba kuvvet saldırısının etkinliğini artıracak bilgi edinilebilir.
Credential’ların Güvensiz Dağıtımı: Eğer kayıt sırasında tüm credential’lar girilmiyorsa daha sonra bunların nasıl dağıtıldığı incelenmelidir. Hesap aktivasyonunda bir URL linki kullanılıyorsa birden fazla kayıt yaptırarak bu linklerin tahmin edilip edilemeyeceğini, aynı linkin birden fazla kez kullanılıp kullanılamayacağını, kilitlenmiş bir hesap için ilk aktivasyon kaydının kullanılıp kullanılamayacağını denetlemek gereklidir.
Bazen tasarımı iyi yapılan kontroller uyarlama safhasında açıklar doğurabilirler. Bu açıklar bilgi sızdırma, login kontrolünün tamamen geçersiz kılınması, ya da kurgulanan sistemin güvenlik seviyesini düşürücü nitelikte olabilir.
Fail-Open Login Mekanizmaları: Kullanıcı tanılama yapan rutin eğer bir nedenden dolayı hata alırsa “catch” bloğunda gerekli kontrol bulunmadığından sonra gelen statement’lar çalışarak kullanıcıyı login olmuş gibi kabul edebilir. Tabi burada kullanıcı kimliği tespit edilemeyeceğinden nasıl bir fonksiyonaliteye ulaşılabileceğini kestirmek kolay değildir, ancak yine de kritik veri veya fonksiyonaliteye ulaşmak mümkün olabilir.
Denetim prosedürü olarak login sırasında proxy ile gönderilen ve alınan tüm verileri belirlemeli ve aşağıdaki varyasyonlarda istekleri tekrar göndermeliyiz:
- Verileri sırayla veya belli kombinasyonlarda boş göndermek
- Parametre/Değer çiftlerinin tamamen kaldırılması
- Çok uzun veya çok kısa değerler göndermek
- Numerik değerler yerine metin, metin değerler yerine numerik veri göndermek
- Aynı parametreyi aynı ve farklı değerlerle birden fazla defa aynı mesaj içinde göndermek
Çok Aşamalı Login Açıklıkları: Çok aşamalı bir kullanıcı tanılama kullanıcı kodu ve password’ünün istenmesi, kullanıcının bildiği bir bilginin veya PIN numarasının istenmesi, fiziksel bir token’ın ekranındaki tek kullanımlık parolanın girilmesi gibi birden çok faktörün farklı form sayfalarından girilmesi şeklinde gerçekleştirilir. Çok aşamalı kullanıcı tanılama genellikle güvenlik açısından daha güçlü sayılır. Ancak hatalı bir uygulama daha basit bir kullanıcı tanılamanın da altında bir güvenlik sağlayabilir.
Çok aşamalı kullanıcı tanılama prosesleri şu güvensiz varsayımları içerebilir:
- 3. aşamaya ulaşmış bir kullanıcının zaten 1. ve 2. aşamaları başarı ile geçtiği varsayılıyor olabilir. Bu nedenle doğrudan 3. aşamaya erişen bir kullanıcı authenticate edilebilir.
- 2. aşamada kullanıcı tarafından gönderilen bir veriye 1. aşamada zaten kontrol edildiğinden sorgulamadan güvenilebilir. 2. aşamada kullanıcı bu veriyi değiştirerek kullanıcı hesabını, kullanıcı grubunu, vb. bağlamları değiştirebilir.
- Uygulama her aşamada aynı kullanıcı için işlem yapıldığını varsayarak kontrol etmeyebilir. Örneğin ilk aşamada kullanıcı kodu ve password’ü doğrulandıktan sonra kullanıcı kodu hidden bir alanda 2. aşamada gönderilirken OTP password’ü girilebilir. 2. aşamadaki kullanıcı kodu değiştirilerek farklı bir kullanıcı’ya ait OTP değeri gönderilebilir. Bu durum kendi OTP’sine sahip bir kullanıcının başka bir kullanıcının kullanıcı adı ve password’ünü ele geçirmesi durumunda diğer kullanıcı gibi, veya tam tersi şekilde login olmasını sağlayabilir.
- Login adımlarının farklı sırada gerçekleştirilmesi
- Doğrudan ileriki bir aşamaya geçilmesi
- Birden fazla defa gönderilen parametrelerin değiştirilerek gönderilmesi ve bunlara güvenilip güvenilmediği veya kullanılıp kullanılmadıklarının test edilmesi
- Farklı aşamalarda farklı kullanıcıların credential’larının kullanılması
- Kullanıcı tarafından doğrudan girilmemiş ancak sunucu tarafından login prosesinin statüsünü kontrol etmek için atanmış değerlerin değiştirilmesi
- Defalarca login olmaya çalışarak kolay soru seçilmesi
- Eğer soru ve cevabı bir arada gönderiliyorsa istek içinde sorunun bilinen bir soruyla değiştirilmesi denenebilir.
Denetim prosedürü olarak eğer bir komut veya SQL injection açıklığı bulunursa kullanıcı kodları ve password’lerine erişimin mümkün olup olmadığı denetlenmelidir.
<<Önceki Bölüm Sonraki Bölüm>>
BTRiskBLOG, BTRİSK Bilgi Güvenliği ve BT Yönetişim Hizmetleri şirketi personeli tarafından geliştirilen Pentest (Sızma Testi), ISO27001, BT Denetimi ve bilgi güvenliği hakkında herşeyi bulabileceğiniz blog'dur.
