Sızma Testleri (Pentests): Web Uygulama Sızma Testleri İçin Kontrol Listeleri: II

Checklist for Web Application Pentesting - II

Kullanıcı credential bilgileri açık metin (clear text) olarak gönderilmemeli.
Şifremi unuttum ve şifre sıfırlama fonksiyonları doğru yapılandırılmış mı?
Kullanıcı şifreleri zorluk dereceleri test edilmeli.
Özellikle login ve bilgi kayıt sayfalarının brute force (kaba kuvvet) saldırılarına açık olup olmadığı test edilmeli.
Belirli bir aralıkta şifrenin değiştirilmesi vb. güvenlik önlemleri var mı?
Şifre değiştirmede eski şifrenin sorulması vb. güvenlik önlemleri alınmış mı?

Uygulamanın teknik altyapısı belirlendikten sonra, ilgili ana çatıya ait varsayılan kullanıcı adı ve şifre bileşenleri test edilmelidir.

Testi gerçekleştirilen uygulamaya yada uygulamanın sahibi şirkete ait özel kelimeler kullanıcı adı ve şifre olarak test edilebilir.
Ön tanımlı (default) değerler varsa (kullanıcı adı ve/veya şifre için), bu değerler test edilmelidir.
Kullanıcı adı tahmini: Sistem tarafından otomatik kullanıcı adı veriliyor/öneriliyor olabilir. "user0015" gibi bir kullanıcı adıyla karşı karşıyaysak geçerli kullanıcı adları tahmin etmek zor olmayacaktır.

Uygulama ya da web servisleri “Basic Authentication” kullanarak kimlik doğruluyor ise araya girme saldırılarında kullanıcı adı ve şifreler elde edilebilir.
Ne tür bir kimlik doğrulama yapıldığı kontrol edilmelidir. Digest Authentication ve bazı koşullarda SSL bağlantı üzerinden yapılan transferler güvenli olarak kabul edilebilir.

Korunan sayfanın doğrudan çağrılması (forced browsing): Uygulama sadece giriş (login) sayfası üzerinde oturum kontrolü gerçekleştiriyorsa ve diğer sayfalarda da oturum yerine başka bir değişkenin varlığını kontrol etmekte ise, korunan sayfa doğrudan çağrılabilir.
Parametre değiştirme: Oturum açılması sonrası örneğin kullanıcı ismi parametre olarak uygulamada kullanılıyor olabilir. Bu testlerde amaç oturum bilgisinin sunucu tarafından da tutulduğundan emin olunmasıdır.
Oturum bilgisi tahmini: Kullanıcı her giriş yaptığında uygulama farklı oturum bilgisi tutmakta ve göndermektedir. Profesyonel uygulamalar ve uygulama ana çatıları oturum oluşturma yöntemlerini sunmaktadır ve genellikle yeteri kadar rastgele değerler kullanılmaktadır. Diğer taraftan, kullanıcının oturum bilgisini manüel oluşturması ya da ek bilgi gömmesi durumunda, oturum bilgilerinin analizi faydalı olabilir.
SQL enjeksiyonu: Form alanı bazlı bir kimlik doğrulama gerçekleştiriliyor ise, SQL Enjeksiyonu kullanılarak kimlik doğrulama bypass edilebilir.

Sunucu, login isteğinin karşılığında, istek doğru bile olsa kesinlikle 200 OK dönmemeli, 302 FOUND dönmelidir. Çünkü 200 OK dönüşlerinde browser kullanıcı adı/şifre ikilisini browser cache’inde saklıyor, sayfa yenilendiğinde (refresh) o kullanıcı adına sisteme girilmiş olarak sayfa gelir.

Çıkış fonksiyonun var olduğu mutlaka kontrol edilmelidir. Uygulamaların bir kısmı kullanıcı tarayıcıyı kapattığında, ek bir http isteği göndererek URL içinde oturum bilgisini, oturumu deaktive edecek bir sayfaya gönderebilmektedir. Böyle bir durumun kontrolü yapılmalıdır.
Çıkış bağlantısının beklenilen işlevi gerçekleştirdiği kontrol edilmelidir. Çıkış bağlantısının gerçekten oturumu sonlandırıp sonlandırmadığı da test edilmelidir.

Hassas bilgi içeren sayfalar, tarayıcı önbelleğinde depolanıyor/tutuluyor olabilir; önbellek, logout mekanizması tarafından temizlenmez.
HTTP yanıt (response) başlıklarında “Cache control: no-cache, no-store” olmalı. No-store olmazsa logout yaptıktan sonra tarayıcı “geri” tuşuna basarak login iken gezilen sayfaları sakladığı yerden tekrar getirecektir.