Web uygulamasına sızma testi yaptıracağız ama önce hazırlanmak istiyoruz — kendimiz uygulayacağımız kontrol listesi var mı?

Geçen yıl benzer bir B2B yazılım için 5.000 sterlin ödeyerek test yaptırdık. Ön hazırlık yapmadığımız için raporda çıkan 22 bulgunun 14 tanesi eksik HTTP başlıkları ve varsayılan sunucu yanıtlarıydı. Danışmanın vaktinin en az 1.500 sterlinlik kısmını bu basit şeyleri raporlamaya harcadığını görünce çok pişman olmuştuk.

En kritik konu test ortamının stabilitesidir. Canlı ortam yerine mutlaka canlı verinin anonimleştirilmiş bir kopyasını içeren ayrı bir test sunucusu kurun. Test uzmanı veri tabanını bozabilecek veya kuyrukları şişirebilecek denemeler yaptığında canlı operasyonunuz durmasın. Ayrıca test süresince geliştirme ekibinin ortama yeni kod dağıtmasını (deploy) yasaklayın.

Girdi doğrulama ve şifreleme taraflarına bakın. Form alanlarında ve URL parametrelerinde özel karakter kaçırma işlemlerini kontrol edin. Veritabanına yazılan tüm kullanıcı girdilerinin doğru filtrelendiğinden ve oturum anahtarlarının oturum kapatıldığında sunucu tarafında tamamen geçersiz kılındığından emin olun. Bu tür açıklar testi doğrudan olumsuz etkiler.

Kendiniz test yaparken her şeyi mükemmel hale getirmeye çalışıp ortamı aşırı basitleştirmeyin. Bazen geliştiriciler test kolaylığı olsun diye güvenlik duvarını tamamen kapatıyor veya bazı koruma katmanlarını devre dışı bırakıyor. Sonra raporda temiz çıkan sistem canlıya geçince patlıyor. Test ortamı canlı yapılandırmanın birebir aynası olmalı.

Test uzmanlarına iki farklı yetki grubundan ikişer adet geçerli hesap sağlayın: iki normal kullanıcı ve iki yönetici. Bir de tüm yetkileri kısıtlı bi demo hesabı verin. Böylece kullanıcılar arası yetki atlama ve yatay yetki yükseltme testlerini hemen ilk saatten itibaren sorunsuz yapabilirler.

Anlaşmanız beyaz kutu (white-box) mu yoksa siyah kutu (black-box) mu? Eğer kaynak kodları ve API şemalarını paylaşacaksanız hazırlık aşamasında dokümantasyon eksiklerini kapatmak ilk önceliğiniz olmalı. Uzmana kod erişimi vermeyecekseniz odak noktanız tamamen dışa açık uç noktalar olmalı.

Çok doğru bir yaklaşım sergiliyorsunuz. Kendi hazırlığınızı yapmanız geliştiricilerin güvenlik farkındalığını da ciddi şekilde artırır. Ekiple birlikte bir yarım günlük iç güvenlik çalıştayı yapıp temel OWASP maddelerini kod üzerinde gözden geçirirseniz test sürecinden en yüksek verimi alırsınız.

kesinlikle ip adresini guvenlik duvarinda istisna tanimlayin sonra bizim pentestte uzman ilk gun tamaen engellendi adamlar yarim gun ip actirmak icin mail atti para bosa gitti

Katılıyorum.

Bende tam tersi oldu, o yüzden yazıyorum. Küçük ölçekte işe yarayan çözüm büyüyünce çöküyor, bunu geç öğrendim.

Kararı geri almak ne kdr zorsa, o kdr yavaş verin. ya tecrübeyle sabit.

Buradan gidecekseniz şunu baştan halledin. Kayıt tutmayan hiç bir süreç düzelmiyor, çünkü neyi düzelteceğinizi bilmiyorsunuz.

Benim görüşüm bu kesin doğru diye yazmıyorum.

Buraya kadar söylenenleri özetleyeyim. Otomatik tarama raporu ile sızma testi aynı şey dgl.

Kolay gelsin.

bu başlık arşivlik.

bizde şöyle oldu bir de bunu başan yazılı hâle getirmezseniz sonra tartışma çıkıyor.

unutulmuş test ortamları canlı sistemden daha sık kapı oluyor. sonucu buraya yazarsanız başkalarına da faydası olur.

Farklı düşünüyorum. Ölçmeden karar verince hep aynı yere geliyoruz.

Test edilmemiş bir yedek, yedek değildir. Sorunuz olursa yazın, elimden geldiğince cevaplarım.

web uygulaması sızma testi konusunda hiç tecrübem yok o yüzden soruyorum. Yedeğin aynı ağda ve aynı kimlikle erişilebilir olması onu hedefin parçası yapıyor.

Sorunuz olursa yazın, elimden geldiğince cevaplarım.

tam zamanında bi konu.

Soracağım şey biraz acemice olacak kusura bakmayın. Olayların çoğu zafiyetten değil, sızmış bi paroladan başlıyor.