Selenium Java Otomasyonunu Güvenlik Testlerine Genişletmek
Fonksiyonel Test Otomasyonu Neden Güvenlik Zayıflıklarını da Aramalı
Selenium en çok fonksiyonel tarayıcı otomasyonuyla bilinir: bir sayfayı açmak, veri girmek, butonlara tıklamak, sonuçları doğrulamak ve bu adımları farklı tarayıcı ve ortamlarda tekrarlamak.
Ancak modern web uygulamaları fonksiyonel doğruluktan fazlasına ihtiyaç duyar.
Bir sayfa başarıyla yüklenebilir. Bir kullanıcı giriş yapabilir. Bir ödeme gönderilebilir. Tüm fonksiyonel doğrulamalar geçebilir.
Ve uygulamada yine de ciddi güvenlik zayıflıkları bulunabilir.
Bu da ilginç bir soruyu akla getiriyor:
Mevcut bir Selenium Java otomasyon çerçevesi, işe yarar güvenlik testleri de yapabilir mi?
Cevap: evet — ama bazı önemli sınırlamalarla.
Amaç Selenium'u sızma testi platformlarının yerine koymak değil. Bunun yerine güvenlik kontrolleri, kurumların zaten çalıştırdığı fonksiyonel testlerin yanında koşan otomatik regresyon testlerinin bir katmanı haline gelebilir.
Fonksiyonel Başarı, Güvenlik Başarısı Demek Değildir
Sıradan bir otomatik giriş testini düşünün:
Uygulamayı aç
Kullanıcı adını gir
Şifreyi gir
Giriş'e tıkla
Panoyu doğrula
Çıkış yap
Fonksiyonel açıdan bu yeterli olabilir.
Güvenlik açısından ise pek çok soru cevapsız kalır:
HTTPS doğru kullanıldı mı?
Önemli tarayıcı güvenlik başlıkları (header) döndü mü?
Kimlik doğrulama çerezleri uygun güvenlik bayraklarıyla korunuyor mu?
Oturum kimliği, kimlik doğrulamadan sonra değişti mi?
Hassas bilgiler URL'lerde veya sayfa kaynağında açığa çıkıyor mu?
Daha düşük yetkili bir kullanıcı bir yönetici sayfasına ulaşabiliyor mu?
CSRF koruması var mı?
Kimlik doğrulaması gerektiren içerik yanlış şekilde önbelleğe alınıyor mu?
Çıkış işlemi önceki oturumu gerçekten geçersiz kılıyor mu?
Sunucu veya çerçeve bilgileri gereksiz yere ifşa ediliyor mu?
Geleneksel Selenium test paketleri genellikle bu sorulara cevap vermez; çünkü bunun için tasarlanmamışlardır.
Ama Selenium'da, güvenlik testinin şiddetle ihtiyaç duyduğu bir şey zaten var:
Uygulama bağlamı.
Selenium kullanıcının nerede olduğunu, hangi rolle giriş yapıldığını, hangi sayfaya ulaşıldığını, hangi iş akışının yürütüldüğünü ve bundan sonra ne olması gerektiğini bilir.
Bu bağlam, güvenlik odaklı otomasyonu şaşırtıcı derecede güçlü kılar.
Ek Bir Anahtar Kelime Katmanı Olarak Güvenlik
Anahtar kelime tabanlı bir Selenium çerçevesi zaten şu tür eylemleri destekliyor olabilir:
OpenBrowser
NavigateBrowser
typeInput
clickButton
verifyText
selectDropdown
CloseBrowser
Güvenlik işlevleri de aynı mimariyle eklenebilir.
Örneğin:
SEC_CheckHTTPS
SEC_CheckSecurityHeaders
SEC_CheckCookieFlags
SEC_CheckMixedContent
SEC_CheckSensitiveDataInURL
SEC_CheckSensitiveDataInPageSource
SEC_VerifyCSRFProtection
SEC_CheckSessionRotation
SEC_CaptureAuthenticatedSession
SEC_VerifyOldSessionRejected
Bu yaklaşım, test adımlarının Excel'de veya başka bir veri kaynağında harici olarak tutulduğu hibrit çerçevelerde özellikle kullanışlıdır.
Böylece bir fonksiyonel test hem fonksiyonel test hem de güvenlik regresyon testi olabilir.
Örneğin:
OpenBrowser
NavigateBrowser
SEC_CheckHTTPS
SEC_CheckSecurityHeaders
SEC_CheckSessionRotation
EnterUsername
EnterPassword
ClickLogin
SEC_CheckSessionRotation
SEC_CaptureAuthenticatedSession
SEC_CheckCookieFlags
ExecuteBusinessWorkflow
Logout
SEC_VerifyAuthenticationCookieRemoved
SEC_VerifyOldSessionRejected
SEC_VerifyLogoutRedirect
Güvenlik kontrolleri, tamamen ayrı bir test süreci gerektirmek yerine sıradan, yeniden kullanılabilir otomasyon adımlarına dönüşür.
Zamanlama Önemlidir
Güvenlik anahtar kelimeleri her Selenium testinin sonuna öylece eklenemez.
Bir güvenlik kontrolünün ne zaman çalıştığı, çoğu zaman neyi kontrol ettiği kadar önemlidir.
İşe yarar bir güvenlik testi yaşam döngüsü şöyle görünebilir:
TEST BAŞLANGICI
|
v
GİRİŞTEN ÖNCE
|
|-- HTTPS Doğrula
|-- Güvenlik Başlıklarını Kontrol Et
|-- Karışık İçeriği Kontrol Et
|-- Giriş Korumasını Doğrula
`-- Giriş Öncesi Oturumu Kaydet
|
v
GİRİŞ SIRASINDA
|
|-- Şifre Alanı Güvenliği
|-- Geçersiz Giriş Davranışı
`-- MFA Kontrolleri
|
v
GİRİŞTEN SONRA
|
|-- Oturum Yenileme
|-- Kimliği Doğrulanmış Oturumu Kaydet
|-- Çerez Güvenliği
`-- CSRF Kontrolleri
|
v
KİMLİĞİ DOĞRULANMIŞ İŞ AKIŞI
|
|-- Yetkilendirme
|-- Hassas Veri
|-- Ağ Trafiği
|-- API Güvenliği
`-- Erişim Kontrolü
|
v
ÇIKIŞ
|
v
ÇIKIŞTAN SONRA
|
|-- Kimlik Doğrulama Çerezi Silindi
|-- Önceki Oturum Reddedildi
`-- Korunan Kaynak Engellendi
|
v
GÜVENLİK ANALİZİ / RAPORLAMA
Oturum yenileme (session rotation), zamanlamanın neden önemli olduğunu gösteren iyi bir örnektir.
Oturum kimliğini yalnızca girişten sonra kontrol etmek bize çok az şey söyler.
Daha güçlü bir otomatik test, kimlik doğrulama öncesi oturumu kaydeder, girişi yapar ve ardından kimliği doğrulanmış oturumu ilk oturumla karşılaştırır.
Benzer şekilde, eski bir oturumun hâlâ kullanılabilir olup olmadığını test etmek çıkıştan sonra anlamlıdır, öncesinde değil.
Bu nedenle güvenlik otomasyonu, birbirinden kopuk güvenlik kontrolleri çalıştırmak yerine uygulamanın durumunu anlamaktan fayda görür.
Selenium DOM'dan Fazlasını Test Edebilir
Güvenlik odaklı bir Selenium çerçevesi birkaç katmanda çalışabilir.
Tarayıcı ve Sayfa Güvenliği
Pasif güvenlik kontrolleri şunları inceleyebilir:
HTTPS kullanımı
Karışık içerik (mixed content)
URL'deki hassas parametreler
Sayfa kaynağındaki hassas bilgiler
Tarayıcı konsol mesajları
Önbellekleme davranışı
Şifre alanı yapılandırması
Güvenlikle ilgili HTTP başlıkları
Sunucu bilgisi ifşası
Bu kontroller caziptir; çünkü çoğu, normal fonksiyonel regresyon testleri sırasında görece az ek riskle çalışabilir.
Kimlik Doğrulama ve Oturum Güvenliği
Selenium, gerçek kullanıcı yolculuğunu kontrol ettiği için kimlik doğrulama ve oturum testlerinde özellikle kullanışlıdır.
Anonim
|
v
Kimlik doğrulanıyor
|
v
Kimliği doğrulanmış
|
v
Yetkili iş akışı
|
v
Çıkış
|
v
Kimliği doğrulanmamış
Selenium kullanıcının bu yaşam döngüsünde nerede olduğunu bildiği için otomasyon şunları test edebilir:
Oturum yenileme
Çıkışta oturumun geçersiz kılınması
Kimlik doğrulama çerezleri
Oturum zaman aşımı davranışı
Korunan sayfa davranışı
Rol kısıtlamaları
Doğrudan URL erişimi
Yatay erişim kontrolü
Dikey erişim kontrolü
Bu, fonksiyonel otomasyonu güvenlik testiyle birleştirmenin özellikle değerli olabildiği bir alandır.
Yetkilendirme Testleri
Güvenlik odaklı bir Selenium çerçevesi şu tür soruları otomatikleştirebilir:
A Kullanıcısı, B Kullanıcısına ait bir nesneye erişebilir mi?
Ya da:
Normal bir kullanıcı bir yönetici URL'sine doğrudan erişebilir mi?
Ya da:
Bu yetkiye sahip olmaması gereken bir kullanıcı, yönetici işlevlerine erişebiliyor mu?
Bu testler çok değerli olabilir; çünkü fonksiyonel otomasyon çerçevesi bu kaynaklara ulaşmak için gereken kullanıcı hesaplarını, locator'ları, URL'leri, test verilerini, kimlik doğrulama akışlarını ve iş akışlarını çoğu zaman zaten içerir.
Her şeyi ayrı bir güvenlik aracında yeniden kurmak yerine, mevcut fonksiyonel çerçeve bu bilgiyi yeniden kullanabilir.
Ancak bir butonu kullanıcı arayüzünde gizlemek, sunucu tarafında yetkilendirmeyi uygulamakla aynı şey değildir.
Bu nedenle iyi bir güvenlik testi hem kullanıcı arayüzü davranışını hem de mümkünse korunan kaynağa doğrudan erişimin gerçekten reddedilip reddedilmediğini doğrulamalıdır.
Ağ Farkındalıklı Güvenlik Testi
Modern Selenium yetenekleri, ekranda görünen sayfanın ötesinde görünürlük sağlayabilir.
Tarayıcıya ve uygulamaya bağlı olarak ağ odaklı güvenlik kontrolleri şunları inceleyebilir:
HTTP İstekleri
HTTP Yanıtları
Durum Kodları
İstek Başlıkları
Yanıt Başlıkları
Üçüncü Taraf İstekleri
Hassas Veri İfşası
Beklenmeyen Ağ İletişimi
Bu, sıradan arayüz otomasyonu ile güvenlik analizi arasındaki boşluğun bir kısmını kapatmaya yardımcı olur.
Örneğin bir Selenium testi finansal bir işlem yaparken çerçeve ilgili ağ trafiğini gözlemleyebilir.
Güvenlik katmanı daha sonra hassas değerlerin isteklerde, URL'lerde veya yanıtlarda beklenmedik şekilde açığa çıkmadığını doğrulayabilir.
API Güvenliği de Aynı Çerçevenin Parçası Olabilir
Her güvenlik testi bir tarayıcı gerektirmez.
Bir Selenium Java çerçevesi, tarayıcı güvenliği anahtar kelimelerinin yanında API güvenliği anahtar kelimeleri de içerebilir.
Örnekler:
SEC_API_CheckAuthentication
SEC_API_CheckAuthorization
SEC_API_VerifyMissingTokenRejected
SEC_API_CheckHTTPMethods
SEC_API_CheckContentType
SEC_API_CheckSchemaValidation
SEC_API_CheckRateLimit
SEC_API_CheckJWT
SEC_API_CheckJWTClaims
SEC_API_CheckTokenExpiration
SEC_API_CheckSensitiveData
Bu sayede tek bir otomasyon çerçevesi hem kullanıcı arayüzü iş akışını hem de ilgili API'leri doğrulayabilir.
Örneğin Selenium, tarayıcı üzerinden uygulama durumunu oluşturabilir veya değiştirebilir.
Ardından bir API güvenlik testi, arka ucun bu durumu düzgün şekilde koruyup korumadığını doğrulayabilir.
Yalnızca API'ye yönelik güvenlik regresyon testleri hiç tarayıcı başlatmadan da çalışabilir.
Bu, güvenlik katmanının aynı otomasyon mimarisinin parçası olarak kalırken Selenium'un ötesine genişlemesini sağlar.
Selenium'u OWASP ZAP ile Entegre Etmek
Selenium, OWASP ZAP gibi özel bir dinamik güvenlik test aracıyla birlikte kullanıldığında daha da ilginç hale gelir.
ZAP, tarayıcı ile uygulama arasına giren (intercepting) bir proxy olarak çalışabilir.
Akış şöyle olur:
Selenium
|
v
Tarayıcı
|
v
OWASP ZAP
|
v
Uygulama
Selenium gerçekçi iş akışlarını yürütürken ZAP trafiği gözlemler.
Otomasyon şu tür işlemleri yönetebilir:
ZAP Oturumunu Başlat
Selenium İş Akışını Çalıştır
Pasif Taramanın Bitmesini Bekle
ZAP Uyarılarını Al
Uyarıları Güvenlik Bulgusu Olarak İçe Aktar
Güvenlik Kalite Kapılarını Uygula
Güvenlik Raporu Oluştur
Bu birleşim değerlidir; çünkü tarayıcı (scanner), gerçek uygulama iş akışlarının ürettiği trafiği görür.
Buna, bağımsız bir tarayıcının (crawler) ulaşmakta zorlanabileceği kimlik doğrulamalı alanlar da dahildir.
Bir Selenium testi zaten nasıl giriş yapılacağını, menülerde nasıl gezinileceğini, uygulama kayıtlarının nasıl açılacağını, formların nasıl gönderileceğini ve korunan sayfalara nasıl ulaşılacağını bilir.
Güvenlik tarayıcısı bu mevcut otomasyondan yararlanabilir.
Aktif tarama da entegre edilebilir, ancak net bir sınır gerektirir.
Aktif zafiyet denemeleri yalnızca test edilmesine açıkça izin verilmiş sistemlerde çalıştırılmalıdır.
Bunlar normalde sıradan pasif regresyon testlerinden ayrı tutulmalıdır.
Güvenlik Bulguları PASS ve FAIL'den Fazlasını Gerektirir
Geleneksel fonksiyonel otomasyon üç temel sonuçla rahattır:
PASS
FAIL
SKIP
Güvenlik bulguları çok daha fazla bağlam gerektirir.
Otomasyonun şunu raporladığını varsayalım:
SEC_CheckSecurityHeaders : FAIL
İşe yarar bir güvenlik raporu burada durmamalıdır.
Ne olduğunu açıklamalıdır.
Örneğin:
Ne Bulundu
Uygulama yanıtında, beklenen bir veya daha fazla tarayıcı güvenlik başlığı eksik.
Beklenen Davranış
Uygulama, test edilen kaynak için uygun güvenlik başlıklarını döndürmelidir.
Neden Önemli
Güvenlik başlıkları, çeşitli saldırı türlerine ve bilgi ifşasına karşı tarayıcı tarafında derinlemesine savunma sağlar.
Gerçek Sonuç
Rapor tam olarak hangi başlıkların eksik olduğunu belirtmelidir.
Önerilen Düzeltme
Uygun yanıt başlıklarını uygulama, web sunucusu, ters proxy, API ağ geçidi veya yük dengeleyici seviyesinde yapılandırın.
Olgun bir otomatik güvenlik bulgusu şunları içerebilir:
Bulgu ID
Güvenlik Kontrolü
Önem Derecesi
Güvenlik Kategorisi
Etkilenen URL
Test Senaryosu
Ne Test Edildi
Ne Bulundu
Beklenen Davranış
Gerçek Davranış
Sorun Neden Önemli
Olası Saldırı / Risk
Kanıt
Önerilen Düzeltme
OWASP Eşlemesi
CWE Eşlemesi
ASVS Eşlemesi
Otomatik Güven Düzeyi
Manuel Doğrulama Gereksinimi
Yanlış Pozitif Değerlendirmeleri
Bu, bir Selenium hatasını bir geliştiricinin, test uzmanının, güvenlik mühendisinin veya yöneticinin gerçekten inceleyebileceği bir şeye dönüştürür.
Yanlış Güven Duygusundan Kaçınmak Kritiktir
Güvenlik otomasyonunun, sıradan fonksiyonel testlerde daha az karşılaşılan önemli bir sorunu vardır:
Bir gözlem, her zaman bir zafiyetin kanıtı değildir.
Otomatik bir çıkış testinin, daha önce kaydedilmiş bir oturumla korunan bir kaynağa erişmeye çalıştığını düşünün.
Sunucu şu yanıtı verir:
HTTP 200
Çerçevenin şunu raporlaması cazip olabilir:
YÜKSEK - Oturum çıkıştan sonra da geçerli.
Ama tek başına HTTP 200 bunu kanıtlamaz.
Sunucu şunlardan birini döndürmüş olabilir:
Bir giriş sayfası
Bir erişim reddedildi sayfası
Genel bir açılış sayfası
Bir hata sayfası
Gerçekten korunan, kimlik doğrulamalı içerik
Bu nedenle otomasyon daha dikkatli bir şey raporlamalıdır, örneğin:
Olası eski oturum yeniden kullanımı tespit edildi.
Otomatik Güven Düzeyi: Orta
Manuel Doğrulama: Önerilir
Bu ayrım önemlidir.
Bir güvenlik otomasyon çerçevesi üç seviyeyi ayırt etmelidir:
Gözlem
|
v
Olası Bulgu
|
v
Doğrulanmış Bulgu
CSRF de İyi Bir Örnektir
Otomasyonun bir POST formunu incelediğini ve görünür bir anti-CSRF token'ı bulamadığını varsayalım.
Şunu raporlamak cazip olabilir:
CSRF zafiyeti tespit edildi.
Ama bu sonuç yanlış olabilir.
Uygulama şunları kullanıyor olabilir:
SameSite çerezleri
Özel istek başlıkları
Çerçeve düzeyinde sahtecilik önleme (antiforgery) mekanizmaları
Origin doğrulaması
Otomatik kontrolün tanımadığı başka bir koruma yöntemi
Daha iyi bir otomatik sonuç şöyle olurdu:
Tanınan, görünür bir anti-CSRF token'ı tespit edilmedi.
Bulgu Durumu:
Olası Bulgu
Otomatik Güven Düzeyi:
Orta
Manuel Doğrulama:
Önerilir
Bu, gerçekte kanıtlanmamış bir zafiyet iddia etmekten çok daha profesyoneldir.
Bu nedenle iyi bir güvenlik otomasyonu; kanıtı, güven düzeyini, olası yanlış pozitif koşullarını ve manuel doğrulamanın önerilip önerilmediğini raporlamalıdır.
En Büyük Fayda Güvenlik Regresyon Testi Olabilir
Bir zafiyeti bir kez bulmak değerlidir.
Altı ay sonra zafiyetin geri geldiğini otomatik olarak tespit etmek ise daha da değerli olabilir.
Güvenlik odaklı bir otomasyon çerçevesi, kabul edilmiş bir referans noktası (baseline) oluşturabilir.
Örneğin:
Güvenlik Puanı: 91
Kritik Bulgular: 0
Yüksek Bulgular: 0
Orta Bulgular: 2
Düşük Bulgular: 4
Uygulamanın gelecekteki bir derlemesi şunu üretebilir:
Güvenlik Puanı: 76
Kritik Bulgular: 0
Yüksek Bulgular: 1
Orta Bulgular: 4
Düşük Bulgular: 5
Çerçeve yeni çalıştırmayı kabul edilmiş referans noktasıyla karşılaştırabilir.
Bulguları şu şekilde sınıflandırabilir:
YENİ
ÇÖZÜLDÜ
TEKRARLAYAN
ÖNEMİ ARTTI
ÖNEMİ AZALDI
Bu da şu tür güvenlik regresyon kurallarını mümkün kılar:
Yeni Kritik > 0 ise derlemeyi başarısız say
Yeni Yüksek > 0 ise derlemeyi başarısız say
Güvenlik Puanı < 80 ise derlemeyi başarısız say
Puan Düşüşü > 5 ise derlemeyi başarısız say
Bu, güvenlik testini ara sıra yapılan bir faaliyetten sürekli güvenlik regresyon testine dönüştürür.
CI/CD'de Güvenlik Testi
Güvenlik kontrolleri tekrarlanabilir otomasyon adımlarına dönüştüğünde CI/CD hatlarına dahil olabilir.
Bir hat şu adımları içerebilir:
Uygulamayı Derle
Test Ortamına Dağıt
Fonksiyonel Regresyonu Çalıştır
Pasif Güvenlik Regresyonunu Çalıştır
API Güvenlik Testlerini Çalıştır
Onaylı Dinamik Güvenlik Testlerini Çalıştır
Güvenlik Bulgularını Oluştur
Referans Noktasıyla Karşılaştır
Güvenlik Kalite Kapısını Uygula
Raporları Yayınla
Önemli olan, güvenliğin normal yazılım geliştirme geri bildirim döngüsünün bir parçası haline gelmesidir.
Geliştiriciler, belirli türdeki güvenlik regresyonlarını keşfetmek için artık sürüm döngüsünün sonunu beklemek zorunda kalmaz.
Bu, resmi güvenlik testlerini ortadan kaldırmaz. Daha erken geri bildirim sağlar.
Yapay Zekâ Nerede Yardımcı Olabilir — ve Nerede Olmamalı
Yapay zekâ, özellikle bulguları yorumlarken güvenlik otomasyonunu güçlendirebilir.
Deterministik otomasyonun şunu bulduğunu varsayalım:
Eksik Güvenlik Başlıkları:
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Yapay zekâ şu konularda yardımcı olabilir:
Bu başlıkların neden önemli olduğunu açıklamak
Düzeltme önermek
Takip niteliğinde güvenlik testleri önermek
Geliştirici dostu bir açıklama üretmek
Yönetici özeti hazırlamak
İlgili OWASP veya CWE kategorilerini önermek
Ek doğrulama önermek
Ancak orijinal deterministik güvenlik kontrolünün geçip geçmediğine karar vermek yapay zekânın sorumluluğunda olmamalıdır.
Daha güvenli bir mimari şöyledir:
Selenium / API / ZAP
|
v
Deterministik Kanıt
|
v
Güvenlik Bulgusu
|
v
Yapay Zekâ Analizi
Önce kanıt gelmelidir.
Yapay zekâ analizi zenginleştirmeli, kanıt üretmemelidir.
Bu ayrım, yapay zekâ güvenlik testlerine dahil edildiğinde son derece önemlidir.
Selenium'a Güvenlik Testi Eklemenin Avantajları
En büyük avantaj yeniden kullanımdır.
Kurumların elinde şunları içeren binlerce Selenium testi olabilir:
Kimlik doğrulama akışları
Uygulama içi gezinme
Role özel kullanıcılar
İş verileri
Ekran görüntüleri
Raporlar
CI/CD entegrasyonu
Ortam yapılandırması
Yıllara dayanan uygulama bilgisi
Bir güvenlik katmanı bu yatırımı yeniden kullanabilir.
Sürekli Güvenlik Regresyonu
Güvenlik kontrolleri yalnızca ara sıra yapılan güvenlik değerlendirmelerinde değil; her gece, her derlemede veya ilgili her sürümde kontrol edilebilir.
Kimlik Doğrulamalı Uygulama Kapsamı
Selenium, kimlik doğrulaması yapmayan tarayıcıların kolayca keşfedemeyeceği iş akışlarına ulaşabilir.
İş Bağlamı Farkındalığı
Otomasyon kullanıcıları, rolleri, nesneleri, işlemleri, iş akışlarını ve beklenen uygulama davranışını anlar.
Tekrarlanabilirlik
Bir güvenlik bulgusu, onu üreten otomatik iş akışıyla birebir ilişkilendirilebilir. Geliştiriciler aynı adım dizisini tekrar oluşturabilir.
Birleşik Fonksiyonel ve Güvenlik Kanıtı
Tek bir çalıştırma iki farklı soruyu cevaplayabilir:
Uygulama çalışıyor mu?
ve
Önemli bir güvenlik kontrolü geriledi mi?
Daha Erken Geri Bildirim
Geliştiriciler belirli güvenlik sorunlarını resmi bir sızma testinden önce öğrenebilir.
Yeniden Kullanılabilir Güvenlik Profilleri
Farklı uygulama türleri için ortak güvenlik kontrolü grupları oluşturulabilir:
Herkese Açık Web Siteleri
Kimlik Doğrulamalı Uygulamalar
Yönetici Portalları
API'ler
Dosya Yükleme İş Akışları
Tam Güvenlik Regresyon Paketleri
Bu, güvenlik testini standartlaştırmayı kolaylaştırır.
Dezavantajlar ve Sınırlamalar
Aynı derecede önemli sınırlamalar da vardır.
Selenium Bir Sızma Testi Aracı Değildir
Güvenlik anahtar kelimeleri eklemek Selenium'u Burp Suite'e, OWASP ZAP'a, bir altyapı tarayıcısına, bir kaynak kod güvenlik analizörüne veya profesyonel bir sızma testi uzmanına dönüştürmez.
Pek çok zafiyet şunları gerektirir:
Özel güvenlik araçları
İnsan muhakemesi
Altyapı görünürlüğü
Kaynak kod analizi
Tehdit modelleme
Zincirleme saldırı senaryoları
Derin uygulama bilgisi
Selenium güvenlik otomasyonu bu faaliyetleri tamamlamalı, onların yerini almamalıdır.
Yanlış Pozitifler Mümkündür
Otomatik gözlemler bağlam gerektirir.
Eksik bir başlık belirli bir kaynak için kasıtlı olabilir. Bir çerez, kimlik doğrulama çerezi değil bir analitik çerezi olabilir. Bir HTTP 200 yanıtı, erişim reddedildi sayfası içerebilir.
Bu nedenle güvenlik otomasyonu sonuçları abartmaktan kaçınmalıdır.
Yanlış Negatifler Mümkündür
Tüm otomatik güvenlik kontrollerinden geçmek, bir uygulamanın güvenli olduğu anlamına gelmez.
Çerçeve yalnızca uygulanmış güvenlik koşullarını test etmeyi bilir.
Bir saldırgan ise otomasyon çerçevesindeki test senaryolarıyla sınırlı değildir.
Bakım Yükü Artar
Güvenlik kontrolleri de birer yazılımdır. Bakım gerektirirler.
Tarayıcılardaki, kimlik doğrulama sistemlerindeki, API mimarisindeki, uygulama çerçevelerindeki, güvenlik politikalarındaki ve uygulama davranışındaki değişiklikler, güvenlik otomasyonunun güncellenmesini gerektirebilir.
Aktif Testler Risk Taşır
Pasif gözlem, rutin QA regresyonu için genellikle daha uygundur.
Aktif zafiyet denemeleri ise farklıdır. Şunlara yol açabilirler:
Uygulama Verilerini Değiştirmek
Olağandışı Trafik Üretmek
Güvenlik Savunmalarını Tetiklemek
Çok Sayıda İstek Oluşturmak
Uygulama Kararlılığını Etkilemek
Bu nedenle aktif testler açıkça etkinleştirilmeli ve yetkili ortamlarla sınırlandırılmalıdır.
Güvenlik Uzmanlığı Hâlâ Gereklidir
Otomasyon şunu tespit edebilir:
Bu yanıtta CSRF koruması yok gibi görünüyor.
Bir güvenlik uzmanının yine de şunu belirlemesi gerekebilir:
Bu durum, bu uygulamanın mimarisinde gerçekten istismar edilebilir mi?
Bu ayrım önemlidir.
Selenium Güvenlik Otomasyonu Güvenlik Testlerini Tamamlamalı, Yerini Almamalı
En güçlü model şu değildir:
Sızma Testi
yerine
Selenium
Daha güçlü model şudur:
Fonksiyonel Otomasyon
+
Güvenlik Regresyon Otomasyonu
+
Statik Uygulama Güvenlik Testi (SAST)
+
Yazılım Bileşen / Bağımlılık Analizi
+
Dinamik Uygulama Güvenlik Testi (DAST)
+
Manuel Güvenlik Testi
+
Sızma Testi
Her katman farklı türde sorunları yakalar.
Selenium'un rolü özellikle tekrarlanabilir, uygulama bağlamını bilen güvenlik kontrollerinde öne çıkar.
Fonksiyonel ve Güvenlik Testleri Birlikte Çalışabilir
Geleneksel olarak fonksiyonel test ve güvenlik testi çoğu zaman ayrı disiplinler olarak var olmuştur.
Fonksiyonel otomasyon şunu sorar:
Kullanıcı iş akışını tamamlayabiliyor mu?
Güvenlik testi ise şunu sorar:
İş akışı kötüye kullanılabilir mi?
İkisinin yönlerini birleştirmek daha ilginç sorular ortaya çıkarır.
Örnek 1 — Hesap Erişimi
Fonksiyonel Test
Normal bir kullanıcı kendi hesabını açabiliyor mu?
Güvenlik Uzantısı
Aynı kullanıcı bir kimlik değerini değiştirerek
başka birinin hesabını açabiliyor mu?
Örnek 2 — Çıkış
Fonksiyonel Test
Çıkış çalışıyor mu?
Güvenlik Uzantısı
Önceki kimliği doğrulanmış oturum,
çıkıştan sonra korunan kaynaklara
hâlâ erişebiliyor mu?
Örnek 3 — Dosya Yükleme
Fonksiyonel Test
Bir kullanıcı belge yükleyebiliyor mu?
Güvenlik Uzantısı
Uygulama beklenmeyen veya
tehlikeli dosya türlerini reddediyor mu?
Örnek 4 — Yönetim
Fonksiyonel Test
Bir yönetici, yönetim
sayfasına erişebiliyor mu?
Güvenlik Uzantısı
Normal bir kullanıcı aynı yönetim
URL'sine doğrudan gidebiliyor mu?
Mevcut Selenium otomasyonu, güvenlik testlerine işte burada önemli bir değer katabilir.
Güvenlik Testi, Kalite Mühendisliğinin Parçası Haline Gelir
Pek çok kurumda güvenlik testi geçmişte geliştirmenin sonlarına doğru yapılırdı.
Uygulama geliştirilir. Fonksiyonel testler tamamlanır. Ardından bir güvenlik ekibi değerlendirme yapar.
Geç keşfedilen sorunları düzeltmek pahalı olabilir.
Güvenlik odaklı otomasyon bu sürecin bir kısmını değiştirir.
Belirli güvenlik kontrolleri normal regresyon testleri sırasında sürekli olarak kontrol edilebilir.
Böylece bir güvenlik regresyonu günler hatta haftalar önce fark edilebilir.
Bu, otomatik kontrollerin uzman güvenlik değerlendirmelerinin yerini alabileceği iddiasına girmeden, güvenliği sola kaydırma (shift left) fikrini destekler.
Test Otomasyonunun Doğal Evrimi
Test otomasyonu geleneksel olarak şunu sorar:
Uygulama çalışıyor mu?
Modern kalite mühendisliğinin ise giderek daha fazla şunu sorması gerekiyor:
Uygulama doğru, güvenilir ve güvenli şekilde çalışıyor mu?
Olgun bir Selenium çerçevesi, uygulama iş akışlarını çoğu genel araçtan daha iyi anlar. Şunları bilir:
Kullanıcıların Nasıl Kimlik Doğruladığını
Önemli Uygulama Sayfalarının Nerede Olduğunu
Hangi Rollerin Bulunduğunu
İş İşlemlerinin Nasıl Yürüdüğünü
Hangi Nesnelerin Hangi Kullanıcılara Ait Olduğunu
Hangi İşlemlere İzin Verilmesi Gerektiğini
Hangi İşlemlerin Reddedilmesi Gerektiğini
İş Akışlarının Nasıl Tekrar Oluşturulacağını
Ekran Görüntüsü ve Kanıtın Nasıl Toplanacağını
Raporların Nasıl Oluşturulacağını
Bu çerçeveyi güvenlik odaklı anahtar kelimeler, oturum testleri, API kontrolleri, ağ incelemesi, tarayıcı entegrasyonu, yapılandırılmış bulgular, güvenlik referans noktaları ve regresyon kapılarıyla genişletmek, mevcut bilgiyi değerli bir güvenlik yeteneğine dönüştürebilir.
Bir siber güvenlik ekibinin yerini almaz. Almaya da çalışmamalıdır.
Ama seçilmiş güvenlik testlerini sürekli, tekrarlanabilir, ölçülebilir ve geliştirme yaşam döngüsünde çok daha erken yapılabilir hale getirebilir.
Belki de en değerli sonuç kültüreldir.
Güvenlik, yalnızca yayından önce yapılan bir şey olmaktan çıkar.
Bunun yerine güvenlik, otomasyonun her gün kontrol etmeye yardımcı olabileceği bir başka uygulama kalitesi özelliği haline gelir.
Sonuç
Güvenlik odaklı Selenium otomasyonu, geleneksel fonksiyonel test ile uzman güvenlik değerlendirmesi arasında işe yarar bir orta noktada durur.
Değeri, Selenium'un her zafiyeti bulabileceğini iddia etmesinde değildir.
Değeri; gerçek uygulama iş akışlarına sıkı sıkıya bağlı güvenlik kontrollerini sürekli denetlemesinde, kanıtı korumasında, regresyonları tespit etmesinde ve insanların dikkatini daha derin incelemeyi hak eden alanlara yönlendirmesindedir.
Şunlar göz önünde bulundurularak tasarlandığında:
Net Güvenlik Sınırları
Doğru Çalıştırma Zamanlaması
Yapılandırılmış Kanıt
Güven Düzeyleri
Yanlış Pozitif Farkındalığı
Uygun Manuel Doğrulama
güvenlik regresyon testi, mevcut bir Selenium Java otomasyon stratejisinin pratik bir uzantısı olabilir.
Amaç her Selenium otomasyon mühendisini bir sızma testi uzmanına dönüştürmek değildir.
Amaç otomatik testleri daha güvenlik odaklı hale getirmektir.
Ve uygulamalar karmaşıklaştıkça, güvenlik beklentileri artmaya devam ettikçe, bu yaklaşım modern kalite mühendisliğinin giderek daha önemli bir parçası haline gelebilir.
Yorumlar