◆ Sparround

QA üçün security testing əsasları

Manual QA-dan penetration test gözlənilmir. Amma əsas security yoxlamaları manual testerin gündəlik işinin bir hissəsidir və sığorta/bank sahəsində bu, sadəcə yaxşı olmaq deyil — tələbdir.

QA-nın rolunu düzgün çərçivələmək vacibdir: mən zəiflik siqnalını tuturam və sənədləşdirirəm; istismar etmək və dərin analiz security komandasının işidir. Bu sərhədi interviewdə açıq demək yetkinlik göstəricisidir.

Ən çox rast gəlinən və manual olaraq yoxlanıla bilən problem sinifləri (OWASP-ın klassik siyahısına uyğun): sınıq autentifikasiya və avtorizasiya, IDOR, injection (SQL/XSS), həssas datanın açıq qalması, zəif session idarəetməsi.

Problem sinfiNəyi sınamalıNə görsən bug-dır
Broken access control / IDORURL-də və ya API sorğusunda ID-ni başqasının ID-si ilə əvəz et: /policy/10231 → /policy/10232Başqa müştərinin polisosu/sənədi açılır və ya redaktə oluna bilir
Rol əsaslı avtorizasiyaAdi istifadəçi hesabı ilə admin URL-ini aç; UI-da gizlədilmiş əməliyyatı API ilə çağırƏməliyyat yalnız UI-da gizlədilib, backend icazə yoxlamır
AutentifikasiyaSəhv şifrə ilə dəfələrlə cəhd; logout-dan sonra Back düyməsi; köhnə/expired token ilə sorğuLockout yoxdur, logout-dan sonra səhifə hələ açılır, expired token qəbul olunur
Injection (SQL / XSS)Mətn sahələrinə test payload-ları yaz və nəticəni izlə500 xətası, baza xəta mətni ekranda, script-in icra olunması
Həssas datanın açıq qalmasıDevTools Network-də cavab body-lərinə bax; URL-də parametrləri yoxla; PDF/export fayllarını açCavabda tam kart nömrəsi, FİN, şifrə hash-i; URL-də token və ya şəxsi data
Session idarəetməsiSessiyanın timeout-unu gözlə; eyni hesabla iki cihazdan gir; şifrəni dəyiş və köhnə sessiyanı yoxlaSessiya heç vaxt bitmir, şifrə dəyişəndən sonra köhnə sessiya işləyir

Etik və hüquqi çərçivə — bunu bilmək məcburidir:

  • Security yoxlamaları yalnız test mühitində və yalnız icazə verilmiş sistemlərdə aparılır
  • Production-da security testi yazılı icazəsiz aparılmır — bu, bir çox yurisdiksiyada hüquqi məsuliyyət doğurur
  • Real müştəri datası ilə oynamaq olmaz; test hesabları və maskalanmış data istifadə olunur
  • Tapılan zəiflik açıq kanalda (ümumi chat, ekran paylaşımı) müzakirə olunmur — security komandası və ya lead ilə məhdud kanalda bildirilir
  • Bug report-da payload-ı yazmaq olar, amma real istismar addımlarını və oğurlanmış datanı əlavə etmək olmaz

Bu qaydaları interviewdə xatırlatmaq güclü siqnaldır: göstərir ki, sən yalnız texniki tərəfi yox, məsuliyyəti də başa düşürsən.

Ən yüksək dəyərli və ən asan yoxlama IDOR-dur: URL-dəki və ya API sorğusundakı ID-ni bir vahid dəyişdirib başqa müştərinin datasının açılıb-açılmadığına baxmaq. Sığorta portalında bu, tək bir addımda tapıla bilən ən ciddi problemdir. Interviewdə "Bu formu necə test edərsən?" sualına cavab verərkən security bölməsinə mütləq IDOR-u əlavə et — namizədlərin çoxu bunu unudur.

📚 Mənbələr və sənədlər