Web Uygulama Sızma Testleri İçin Kontrol Listeleri - IV

Checklist for Web App Pentesting - IV

5. Yetkilendirme (Authorization) Testleri

5.1 Yetki Artırımı (Privilege Escalation)

• Yönetici yetkisi “admin=yes”, “true”, “1” gibi bir değişken (gizli bir alanda da olabilir); bu tür değişkenlerin varlığının test edilmesi gerekir.
• POST yada GET istekleri içinde kullanıcı ismi de parametre olarak gönderiliyor ise, bu isim yerine “admin” yada “yonetici” gibi değerlerin yerleştirilip test edilmesi gerekmektedir. Ayrıca “userid” gibi parametreler için de 0 değeri kullanılıp yönetici yetkileri test edilebilir. Benzer şekilde POST isteğinde “Session=A239ffade359fe&role=3” gibi bir veri tespit edilmişse, “role=0” ile daha yetkili haklara sahip olunup olunamayacağı denenmelidir.
• Yatay yetki artırımı için isteklerdeki numerik alanlara dikkat etmek gerekir; bunlar kullanıcı sıra numaraları olabilir.

5.2 Yetki Dışı İşlem

• Yetkilendirme gerektiren fonksiyonlar mutlaka kullanıcı yetki sorgusuna tabi tutulduktan sonra kullanılmalıdır.

5.3 Dizin Gezinimi (Path Traversal)

Dizin gezinimi, herhangi bir GET ya da POST parametresinin bir işletim sistemi dosyasını doğrudan dosya yolu kullanılarak okunması sonucu ortaya çıkar. Örneğin bir POST talebinde “page” isimli bir parametre değeri “header.html” değeri alıyor ise ve ilgili uygulama kodu da bu dosyayı /dosya/yolu/header.html şeklinde çağırıyor ise, “page=../../../../../etc/passwd” gibi bir çağrı ile kullanıcı ve yetki atamaları elde edilmeye çalışılabilir. Özellikle uygulama sunucularının konfigürasyon dosyaları ilginç dosyalar arasındadır.

• Null karakteri (%SıfırSıfır) ile deneme yapmak unutulmamalı. Uygulama, pathin sonuna ".html" vb koyuyor olabilir, bunu atlatmak için.
• Bazen null karakteri soyulup çıkarılıyor olabilir, bir de enter (%0a) göndermekte yarar var.
• Nokta (.) ve slash (/) karakterleri filtreleniyor olabilir, bu durumda bu karakterlerin URL encode değerleri denenebilir. Karakter ve URL kodlama (encoding) karma şekilde de denenmelidir.
• Hata mesajları mutlaka sınanmalıdır. Uygulama, olmayan bir file için (../../../../../blablabla) için "path not found" mesajı verirken var olan bir adres için (../../../../../Program%20Files/) için "permission denied" mesajı veriyor olabilir.

5.4 Yetki Kontrolü Atlatma (Bypassing Authorization)

• Kullanıcı, yetkisi dışında bulunan sayfalara erişebilir mi?  Örneğin AddUser.jsp sayfası sadece admin erişimi için öngörülmekle beraber, standart kullanıcı bu bağlantıyı çağırarak ne tür işlemler yapabilir?
• Yetkimiz olmayan bir işlemin gerçekleştirilmesi mümkün müdür?  Örneğin banka internet sitesi cep telefonu numara değişikliğini yasaklamış olabilir. Fakat uygun bir istek oluşturarak, bu kısıtlama aşılabilir mi?
• Uygulamalar yetki bazlı erişim kontrolünü dokümanlara erişimi denetlemek için kullanıyor olabilirler. Örneğin bütün kullanıcılara ait PDF dosyaları aynı klasörde tutuluyor olabilir. Başka kullanıcıların bilgilerine erişim test edilebilir.
• İsteklerdeki parametreler manipüle edilerek yetkisi olunmayan bilgilere (örneğin oturum açılan kullanıcı dışında başka bir kullanıcının bilgilerine) erişim sağlanabilir.

Web Uygulama Sızma Testleri İçin Kontrol Listeleri - III

Checklist for Web App Pentesting - III

4. Session Management (Oturum Yönetimi) Testleri

4.1. Oturum Sabitleme (Session Fixation) – Giriş Sonrası Oturum Bilgisi Yenileme

• Uygulama login öncesi bir oturum bilgisi gönderiyor ise, login sonrası oturum bilgisinin mutlaka değiştiğine emin olmak gerekmektedir.  Aksi takdirde oturum sabitleme (session fixation) saldırıları test edilebilir. Burada iki senaryo vardır:
• Oturum bilgisi URL içinde taşınıyor ise Session Fixation saldırısı gerçekleştirilebilir.   Bu işlem sadece kullanıcıyı bir bağlantı ziyarete ikna etmek kadar basittir.
• Oturum bilgileri POST talepleri ile taşınıyor ise,  CSRF yöntemi kullanılarak, kullanıcının bizim belirlediğimiz oturum bilgisi ile uygulamaya giriş yapmasını sağlayabiliriz.

4.2. Çerezlerin İçeriği

Set-Cookie: SESSIONID=iojew984389hui78g; path=/appl/portal; secure; HttpOnly

• Çerez mutlaka “HttpOnly” seçeneğini içermelidir. Bu seçenek yeni versiyon tarayıcıların JavaScript kodu kullanılarak çerez bilgisine erişmesini engellemektedir.
• Uygulama SSL üzerinden çalışıyor ise “secure” seçeneğinin de kullanılmış olması gerekmektedir.
• Çerezin etki alanı (domain)  kullanılarak oluşturulması, aynı etki alanı altında çalışan bütün uygulamalara aynı çerezin gönderilmesi anlamına geleceğinden, etki alanının belirtilmemiş olması önemlidir.  Sunucu ismi bazında bir takip yapıldığı kontrol edilmelidir. Yani yanıttaki Set-Cookie başlığında Domain=./example.org gibi bir parametre olmaması beklenir.
• “Path” değişkeni uygun bir korunan alanı işaret etmelidir.  Sadece bu yolun çağrılması durumunda internet tarayıcısı çerez bilgisini gönderecektir.

4.3. Oturum Sonlandırma

• Session timeout varlığı kontrol edilmelidir.
• Uygulama kullanıcıya logout seçeneği sunmalıdır.
• Logout olmadan browser kapatıldığında oturumun sonlandırılıp sonlandırılmadığı kontrol edilmelidir.
• Uygulama beklenmeyen bir hata oluştuğunda (örn: saldırı tesbiti) oturumu sonlandırmalıdır.

4.4. CSRF (Sitelerarası İstek Sahteciliği) ve Oturum Çalma (Session Riding)

CSRF, kurbanın saldırgan tarafından hazırlanmış bir siteyi ziyaret etmesi ve saldırganın kurbana tarayıcısı üzerinden herhangi bir GET ya da POST isteği gönderterek, kurban adına işlem yapması olarak özetlenebilir.

• Hassas işlemlerin GET  (URL)  isteği gönderilerek yapılıp yapılmadığı kontrol edilmeli. Yapılıyor ise mutlaka token (SessionCode)  olarak adlandırılabilecek tek kullanımlık rastgele kodlar üretilip isteklerin doğruluğunu kontrol için kullanılmalı.
• Hassas işlemlerin POST istekleri ile gerçekleştirilmesi durumunda,  rastgele ve her işlemde değişen değerlerin kullanıldığından emin olunmalı.  Kritik POST isteklerini ortaya çıkarmak için sistemde kullanıcı sahibi olmayı gerektirebilir.

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

Checklist for Web Application Pentesting - II

3. Kimlik Denetimi (Authentication) Testleri

3.1. Şifre Politikaları

• 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ı?

3.2. Bilinen Hesap/Şifre bileşenlerinin Denenmesi

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.

3.3. Kullanılan Kimlik Denetimi Tü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.

3.4. Kimlik Doğrulamanın Atlatılması Testleri

• 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.

3.5. Giriş (Login) İşlevi Testleri

• 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.

3.6. Çıkış (Logout) İşlevi Testleri

• Çı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.

3.7. Tarayıcı (Borwser) Önbellek (Cache) Yönetimi

• 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.

Web Uygulama Sızma Testleri İçin Kontrol Listeleri: I

Checklist for Web Application Pentesting 

Bugünden itibaren bir web uygulama sızma testinde temel olarak hangi testlerin yapılması gerektiğini konu edinen bir yazı dizisi oluşturmayı planlıyorum. Plana sadık kalabilirsem bu yazı dizisi, şu yazılardan oluşacak:

1. Application Information
2. Information Gathering & Configuration Management
3. Authentication
4. Session Management
5. Authorization
6. Data Validation
7. Denial of Service

1.  Application Information

• Uygulamanın IP adresi belirlenir.
• Uygulamanın üzerinde çalıştığı uygulama sunucu belirlenir.
• Uygulamada var olan roller ve kayıtlı kullanıcı bilgileri toplanır (Blackbox bir test değilse bu bilgi uygulama sahibinden alınır).
• Uygulama sunucuyu barındıran işletim sistemi tespit edilir.
• Uygulama yazılım dili belirlenir
• Ayrıntılı site haritası çıkarılır (crawling).
• Uygulama girdi (input) alanları belirlenir.
• Uygulamanın çalıştığı ana çatılar belirlenir (Joomla, LifeRay vb.).
• Web servisleri kullanılıp kullanılmadığı tespit edilir.

2. Information Gathering & Configuration Management

2.1. Minimum Bilgi Prensibi Testleri

• Uygulama özellikle uyarı mesajlarında minimum bilgi vermelidir. Örneğin:  “Şifreniz yanlış” ya da “Şifreniz 6 karakter olmalıdır” yerine  “Şifreniz ya da Kullanıcı İsminiz yanlış”  kullanılmalıdır.
• Uyarı mesajlarının kodları da değerlendirilmelidir. Aynı mesaj farklı kodlarla veriliyor olabilir. Örneğin:
• http://www.foo.com/err.jsp?User=baduser&Error=0
• http://www.foo.com/err.jsp?User=gooduser&Error=2
• Sayfa içindeki gizli alanlar dikkatle incelenmelidir; hassas bilgi içeriyor olabilir.
• Talebe dönen yanıtlarda (response) uygulamanın yazıldığı teknoloji hakkında bilgi olup olmadığı kontrol edilmelidir. Örneğin:
• X-Powered-By: ASP.NET
• X-AspNet-Version: 2.0.50727

2.2. Yardım Sayfaları

• Uygulamanın detayları ile ilgili bilgi verebileceğinden yardım sayfaları sadece kayıtlı kullanıcılara gösterilmelidir.

2.3. SSL Kullanımı

• Verinin internet tarayıcısı ile sunucu arasında şifrelenmesini sağlamak için mutlaka SSL kullanılmalıdır. Diğer taraftan SSL hizmeti veriliyor ise kesinlikle aynı uygulama (uygulama bölümü ) için SSLsiz hizmet sunulmamalıdır. Bu özellikle SSLStrip gibi HTTPS bağlantıları HTTP olarak yansıtan araya girme saldırını mümkün kılan ürünlerin kullanılabilmesi nedeniyle önemlidir.
• Sunucu sertifikasının onaylanmış bir sertifika makamı tarafından verilmiş olması ve tarayıcının da bu sertifikayı tanıması zaruridir, kontrol edilmelidir.
• SSL3.1 ve TLS1.1 altı protokoller, belirlenmiş açıklıkları olduğundan kullanılmıyor olmalıdır.

2.4. HTML Açıklama Satırları

• HTML kodunun içine gömülmüş ve daha sonra unutulmuş yorumlar,  kullanıcı bilgisi ya da sistem sürümü ile ilgili bilgiler içerebilirler. Bu nedenle varlıkları kontrol edilmelidir.

2.5. Sunucu Bilgisinin Kısıtlanması

• Özellikle hata sayfalarında sunucu bilgisi (özellikle 400 ve 500'lü HTTP response kodları) kullanıcıya gösterilmektedir. Minimum bilgi prensibi gereğince, bu bilginin saklanması gerekmektedir.
• Ayrıca yanıtta (response) "Server" başlığı bulunup bulunmadığı kontrol edilir.

2.6. Hata Sayfalarının Gösterimi

• Hata sayfaları 400’lü kodlar yerine 200’lü kodlarla tarayıcıya döndürülmeli ve mümkünse standart bir uygulama sayfasının (ana sayfa)  içinde görülebilir bir formatlama ile gösterilmelidir.

2.7. Dosya Uzantılarının Test Edilmesi

• Sitenin hangi tür bir yazılım altyapısına sahip olduğu konusunda bilgi verebilir. Özellikle sayfa kaynağı görüntülenip,  ilgili uzantılara erişilmeye çalışılabilir.  Diğer taraftan, JSP uzantılı bir uygulama PHP sayfalarını da yorumlayabiliyor olabilir.  Dolayısıyla, benzeri bir test bu kapsamda da gerçekleştirilebilir.

2.8. Yedeklenmiş yada Unutulmuş Dosyalar

• Uygulama geliştiricileri betik ya da sayfaları güncellerken, ilgili modüllerin yedeklerini almış olabilir. Örneğin Cp_config.jsp  config.jsp.backup gibi. Bu tür sayfalar henüz geliştirme aşamasında ya da test amaçlı oluşturulduğu için ciddi açıklıklar barındırabilir. Tespit edilmeleri önemlidir.

2.9. Yönetici Arayüzü Erişim Testi

• Test edilen site üzerindeki
• http://sirket.com.tr/admin
• http://sirket.com.tr/yonetici
• http://sirket.com.tr/manager gibi sadece yetkili kullanıcılara açık olması gereken bağlantılar tespit edilmeye çalışılır. Tespit edilmesi durumunda ise gerekli taramalar yapılır.
• Yönetici arayüzleri uygulama sunucuya göre değişebilir ya da web sunucudan farklı bir portta çalışabilir. Örneğin JBOSS JMX-CONSOLE ya da Glassfish Admin arayüzü gibi.

2.10. Desteklenen HTTP metotları ve XST Açıklığı

• HTTP servisi sunucular farklı HTTP metotlarını desteklemekte ve varsayılan kurulumda bu metotların bir kısmı aktiftir.  OPTIONS sorgusu ile hangi metotların desteklendiği bilgisine erişilebilir. OPTIONS sorgusunun kısıtlanması durumunda tarama araçları kullanılarak gerekli bilgiye ulaşmak mümkündür.

2.11. Bilinen Açıklıklar

• Uygulamanın üzerinde çalıştığı uygulama sunucu (hangi versiyon ise), yazıldığı programlama dili, mimarisinde kullanılan framework'ler ve teknolojiler için açıklanmış açıklıklar internetten taranmalı ve bu açıklıklar için gerekli önlemlerin alınıp alınmadığı mutlaka kontrol edilmelidir.

2.12. E-posta Adresleri Tespiti

• Web sayfalarında kaba bir şekilde tutulmuş e-posta adreslerinin varlığı, bu posta adreslerin otomatik tarama araçlarıyla yakalanmasına ve bu adreslerin "spam" e-postaların hedefi haline gelmesine sebebiyet verebilir. Bu tür e-posta adresleri sistemde otomatik araçlar tarafından yakalanamayacak şekilde tutulmalıdırlar. Örneğin:
• abc at hotmail nokta com

Bir sonraki yazı, kimlik denetimi (authentication) konulu test maddeleri üzerine olacak.

HTTP Security Header'ları Neden ve Nasıl Kullanılmalıdır?

Uygulama geliştirirken güvenlik adına genelde input validation ve session management konularına yoğunlaşılır; bu konu biraz ikinci planda kalır.

Mehmet İnce, header'larda güvenlik ayarı ile ilgili çok güzel bir yazı paylaşmış, şiddetle tavsiye edilir:
https://www.mehmetince.net/http-security-headerlari-neden-ve-nasil-kullanilmalidir/

Web Uygulama Sızma Testi Araçları

Bu yazı, web uygulama sızma testleri sırasında kullanılan araç çeşitlerini konu almıştır. Bu araçların hangi amaçla kullanıldığı anlatılarak kullanılabilecek bazı araçlar listelenmiştir. Amaç reklam yapmak değil, o konuda tecrübe sahibi olunan araçların paylaşılmasıdır; araç sahipleriyle hiçbir bağlantım yoktur.

Otomatik Açıklık Tarama Araçları

Web uygulama sızma testlerinde kullanılan en önemli araçlardır. Temel işlevleri, kendisine girdi olarak verilen bir web uygulamasının açıklıklarını tespit edip raporlamaktır. Bu amaçla aşağıdaki işlevleri gerçekleştirirler:

• Uygulama hakkında bilgi toplama. Uygulama sunucu, uygulamanın yazıldığı programlama dili gibi bilgilerin tespitine çalışılır; tam otomatize bir adımdır.
• Uygulama haritasını çıkarmak (crawling, spidering). Genelde tam otomatize bir adımdır; kimi zaman uygulama kullanıcısının müdahalesine ihtiyaç duyulabilir.
• Uygulama login ve logout mekanizmalarının belirlenmesi. Login için genellikle kullanıcı adı / parola gibi özel bilgiler gerekir; hangi yolların (linklerin) de logout olmaya neden olduğunun uygulamaya öğretilmesi gerekir. Bu nedenlerle bu adım genelde uygulama kullanıcısının müdahalesine ihtiyaç duyar.
• Bilinen zafiyetlere göre uygulama zafiyetlerinin tespiti. Otomatize bir adımdır. Bununla birlikte uygulamanın hangi zafiyet türlerine göre taranacağı, saniyede kaç talep (request) gönderileceği, taramanın hangi hassasiyette gerçekleştirileceği gibi ayarlar uygulama kullanıcısı tarafından yapılabilir.

Ticari ya da ücretsiz birçok otomatik tarama aracı mevcuttur. Bunlardan en yaygın kullanılanlarının konu edildiği Temmuz 2014 tarihli bir değerlendirme raporuna (https://www.qualys.com/docs/gartner-magic-quadrant-application-security-testing.pdf) adresinden erişilebilir.Değerlendirmeye göre magic quadrant şu şekilde oluşmuştur:

Değerlendirmeye konu edilen ticari araçlar yanında, açık kaynak kodlu ürünler de mevcuttur. W3AF bunlardan biridir. Ruby ile yazılmış ücretsiz bir araçtır. Ticari ürünlerin olmadığı durumlarda idare edebilecek kadar tarama yapar; ticari ürünler kadar iyi ve etkili değildir. Kendi modüllerinizi yazmanıza izin verir. Yakın zamanda Rapid7 ürünü kendi ürün ailesine katsa da halen açık kaynak bir üründür.

Personal Proxy (Kişisel Vekil Sunucu)

Web uygulama sızma testlerinde kullanılan en önemli araçlardan biri de kişisel vekil sunuculardır. Bu araçlar, istemci ile sunucu arasındaki trafikte araya girerek 7. katman seviyesindeki paketlerin incelenmesine ve yakalanıp değiştirilmesine olanak verir. Gerek manuel açıklık taramaları için, gerekse otomatik tarama araçları tarafından raporlanan zafiyetlerin gerçekten var olup olmadığını incelemek için kullanılır.

PortSwigger tarafından geliştirilmiş Burp Suite aracı, bu amaçla kullanılabilecek ürünlerden biridir. Ücretli olan Pro versiyonu da mevcuttur. Temelde HTTP ve HTTPS trafiğinde araya girme amacıyla kullanılmaktadır. Bunun yanında online kaba kuvvet (brute force) ve sözlük (dictionary) saldırıları, HTTP fuzzing gibi yetenekleri de mevcuttur. Bununla birlikte bir önceki maddede sözü edilen otomatik tarama araçları kadar yetenekli olmasa da zafiyet tarama yeteneği de vardır.

Bir diğer kişisel vekil sunucu da OWASP tarafından geliştirilen ve açık kaynaklı olan ZAP Proxy aracıdır. Bu aracın da zafiyet tarama yeteneği mevcuttur.

Sunucu Tarafı Açıklıkların Taranması

Web uygulama testlerinde birden fazla etkileşim arayüzü bulunmaktadır. Bunlardan biri uygulamanın kendisi ise, bir diğeri de uygulamanın üzerinde barındığı uygulama ve web sunucudur. Bu sunucu sistemlerin güvenliği de en az uygulamanın güvenliği kadar önemlidir.

Sunucu tarafı açıklıkların tespiti için Nessus ve benzeri bir zafiyet tarama aracı kullanılabilir. Ücretli olan Pro versiyonu da mevcuttur. Nessus Pro, sunucu tarafı açıklıkların yanı sıra ön tanımlı (default) değerlerde kalmış kullanıcı adı / parola çiftleri, internete açık şekilde bulunan içerik yönetim sistemi (CMS) arayüzleri, kullanılan SSL versiyonunun denetimi gibi temel düzeydeki web uygulama zafiyetlerini de tespit edebilecek modüllere sahiptir.

Tespit Edilen Zafiyetlerin Sömürülmesi (Exploitation)

Otomatik tarama araçları ya da manüel yollarla tespit edilen açıklıkların yanlış alarm (false positive) olup olmadığının belirlenmesi ve bu açıklıkları kullanarak nereye kadar gidilebileceğinin tespiti de oldukça önemlidir. Sızma testlerini (pentest) zafiyet taramalarından (vulnerability assessment) ayıran en önemli yön de budur.

Genel olarak, diğer tüm sızma testi türlerinde olduğu gibi web uygulama sızma testlerinde de tespit edilen zafiyetlerin sömürülmesi ve sömürü sonrası yapılabileceklerin belirlenmesi için Metasploit aracı kullanılabilir. Ürün ailesi içindeki msfconsole, msfcli, msfvenom ücretsizdir ve komut satırı çalışan ürünlerdir. Ücretli olan Pro versiyonu da mevcuttur ve web arayüzüne sahiptir.

SQL enjeksiyonu, web uygulamaları için en tehlikeli açıklıklardan biridir. Bu nedenle bu açıklıkla neler yapılabileceğinin belirlenmesi ayrıca önemlidir. Bu amaçla SQLMap aracı kullanılabilir. Ücretsizdir, KALI içinde de yer almaktadır. Komut satırı (command line) çalışan bir üründür. Her bir açıklık özel bir durum oluşturduğundan bir sürü parametre içerir; bu nedenle kullanımı oldukça zordur ancak bir o kadar da etkilidir.

Örnek verilebilecek bir diğer SQL enjeksiyonu istismar aracı da Havij’dir. Grafik arayüzü olan bir araçtır, bu nedenle SQLMap’e gönre kullanılışı oldukça basittir. Ticari bir üründür; ücretsiz versiyonu sadece 1-2 VTYS (Veritabanı Yönetim Sistemi) destekler.

Diğer Araçlar

Bunlara ilave olarak özel durumlarda farklı araçlar edinip testlerde kullanılmaya çalışılmaktadır: Web servis testleri olduğu takdirde SOAP UI, “thick client” bir uygulama söz konusu ise HTTP Debugger Pro aracı bu durumlarda kullanılabilecek araçlara örnektir.