Web application security audit Baku xidməti canlı müştəri portalında, daxili əməliyyat sistemində və ya açıq veb tətbiqində kənar istifadəçinin görməməli olduğu məlumatlara, funksiyalara və hesablara çıxış imkanını sistemli şəkildə yoxlamaqdır. Praktik auditin məqsədi yalnız texniki zəiflik tapmaq deyil: hansı istifadəçi rolunun hansı məlumatı oxuya, dəyişə, ixrac edə və ya silə bildiyini təsdiqləmək, riskin biznes təsirini izah etmək və düzəlişin həqiqətən işlədiyini yenidən sınaqdan keçirməkdir.
Bu, xüsusilə Baku şirkətləri üçün vacibdir, əgər tətbiqdə müştəri kabineti, əməkdaş panelləri, sifariş və ödəniş məlumatları, sənədlər, CRM/ERP inteqrasiyası, inzibati panel və ya mobil tətbiqin istifadə etdiyi API mövcuddursa. Platformanı sıfırdan yenidən yazmaq həmişə ilk addım deyil. Çox vaxt düzgün scope ilə aparılan audit mövcud tətbiqdə prioritet riskləri müəyyən edir və təhlükəsiz buraxılış planı yaradır.
Veb tətbiqi təhlükəsizlik auditi nəyi yoxlamalıdır?
Yaxşı website security audit Baku yalnız avtomatik skan nəticələrinə əsaslanmır. Skanerlər məlum konfiqurasiya və giriş nöqtələrini aşkar edə bilər, lakin biznes qaydalarını anlaya bilməz: məsələn, bir filial menecerinin başqa filialın hesabatını görməsi, adi istifadəçinin admin funksiyasını çağırması və ya dəstək əməkdaşının həddindən artıq şəxsi məlumat ixrac etməsi.
Praktik iş proqramın xəritələnməsi ilə başlayır: domenlər və subdomenlər, giriş növləri, istifadəçi rolları, admin panellər, API endpoint-ləri, inteqrasiyalar, fayl saxlama yerləri, fonda işləyən proseslər və kritik məlumat kateqoriyaları müəyyən edilir. Sonra hər hissə icazəli test çərçivəsində yoxlanır.
1. Autentifikasiya və sessiya axınları
Audit qeydiyyat, giriş, parolun bərpası, e-poçt və telefon təsdiqi, çoxfaktorlu autentifikasiya varsa onun tətbiqi, “məni xatırla” mexanizmi, cihaz sessiyaları və hesabdan çıxış davranışını qiymətləndirməlidir. Məqsəd təkcə zəif parol siyasətini tapmaq deyil; tokenlərin düzgün ləğv olunmasını, sessiyanın gözlənilmədən başqa hesaba keçməməsini və hesab bərpası prosesinin hesab ələ keçirilməsinə yol açmamasını yoxlamaqdır.
Burada vacib suallar bunlardır: parol dəyişəndə aktiv sessiyalar qüvvədən düşürmü? İşçi hesabı deaktiv ediləndə onun API tokeni işləməyə davam edirmi? Administrator üçün adi istifadəçidən fərqli qoruma varmı? Login cəhdləri, token yaradılması və həssas hesab əməliyyatları sonradan araşdırıla bilən loglarda görünürmü?
2. Obyekt, funksiya və rol səviyyəsində giriş nəzarəti
Role-based access control audit adətən ən yüksək biznes dəyəri yaradan yoxlamalardandır. Burada eyni rola malik iki ayrı hesab, fərqli rol və imtiyazlı admin hesabı ilə sorğular müqayisə edilir. Məsələn, istifadəçi URL-də və ya API sorğusunda invoice_id, customer_id, document_id və ya tenant_id dəyərini dəyişəndə başqa müştərinin məlumatına çıxış əldə edə bilirmi? Bu, horizontal giriş pozuntusudur.
Vertical giriş pozuntusunda isə adi istifadəçi admin endpoint-i, kütləvi ixrac, istifadəçi yaratma, rol dəyişmə və ya silmə əməliyyatını çağırmağa cəhd edir. UI düyməsinin gizlədilməsi təhlükəsizlik nəzarəti deyil: server hər sorğuda həm istifadəçinin funksiyaya, həm də konkret məlumat obyektinə icazəsini yoxlamalıdır. OWASP test metodologiyası da hər rol üçün həm üfüqi, həm şaquli icazə bypass sınaqlarını nəzərdə tutur.
Audit nəticəsində yalnız “icazə problemi var” qeydi deyil, konkret qayda formalaşmalıdır: rol + funksiya + məlumat sahəsi/obyekti + gözlənilən qərar. Bu cədvəl sonradan avtomatlaşdırılmış regresiya testlərinin əsası ola bilər.
3. API-lər və artıq məlumat açıqlanması
Müasir portalın görünən interfeysi çox vaxt API üzərində işləyir. Buna görə web application security testing API endpoint-lərini ayrıca əhatə etməlidir: autentifikasiya, obyekt səviyyəli icazələr, funksional icazələr, sorğu limitləri, səhv mesajları, CORS siyasəti, köhnə versiyalar və sənədləşdirilməmiş endpoint-lər.
Risk yalnız “başqa istifadəçinin sifarişini görmək” deyil. API lazımsız sahələri də qaytara bilər: daxili statuslar, işçi qeydləri, telefon nömrələri, ünvanlar, maliyyə atributları, administrator bayraqları və ya inteqrasiya identifikatorları. Eyni zamanda yalnız UI-də read-only olan sahə API vasitəsilə dəyişdirilə bilər. Bu səbəbdən cavab modelləri, yazma üçün qəbul edilən sahələr və rol üzrə field-level qaydalar yoxlanmalıdır.
4. Fayl yükləmə, sənədlər və media faylları
Fayl yükləmə funksiyası varsa, audit yalnız uzantının yoxlanması ilə bitməməlidir. Faylın faktiki tipi, ölçü limitləri, adlandırma, antivirus və ya emal zənciri, saxlanma yeri, birbaşa URL-lər, yükləyənin və oxuyanın icazələri nəzərdən keçirilməlidir. Məsələn, müştəri sənədi proqnozlaşdırılan linklə açılırsa və ya köhnə əməkdaşın paylaşım linki qüvvədə qalırsa, tətbiqdə məlumat sızması riski yaranır.
İş qaydası aydın olmalıdır: kim yükləyə bilər, kim görə bilər, kim endirə bilər, paylaşım nə vaxt bitir və silinmiş sənədin keşlənmiş və ya kənar yaddaşdakı nüsxəsi necə idarə olunur?
5. Sirlər, konfiqurasiya, asılılıqlar və inzibati giriş
Audit repozitoriyada və yerləşdirmə mühitində sızmış API açarları, test parolları, səhv konfiqurasiyalar, debug endpoint-ləri, ətraflı stack trace-lər, açıq storage sahələri və həddindən artıq geniş servis icazələrini yoxlamalıdır. Həmçinin tətbiqin istifadə etdiyi paketlər, onların yenilənmə prosesi və kritik zəifliklərə cavab proseduru nəzərdən keçirilməlidir.
Admin girişləri ayrıca scope tələb edir. Buraya istehsal mühitinə giriş, hosting və bulud hesabları, verilənlər bazası, CI/CD, domen və e-poçt sistemləri, müşahidə alətləri və ehtiyat nüsxələr daxildir. Ən yaxşı tətbiq kodu belə, paylaşılmış admin parolu və ya nəzarətsiz keçmiş əməkdaş hesabı səbəbindən risk altında qala bilər.
Faydalı OWASP security assessment ilə checkbox hesabatını necə ayırd etmək olar?
Qısa, generik PDF və yüksək sayda “tapıntı” yaxşı audit demək deyil. Faydalı qiymətləndirmə biznes məntiqini, məlumat axınlarını və real rol modelini test edir. Təklif və yekun hesabatda aşağıdakı elementləri gözləmək məqsədəuyğundur.
- Dəqiq scope: domenlər, API-lər, mobil backend, admin panel, istifadəçi rolları və test mühiti açıq yazılmalıdır.
- İcazəli test qaydaları: istehsal mühitində hansı testlərə icazə verildiyi, məlumatın necə qorunacağı və kritik hal baş verərsə əlaqə kanalı əvvəlcədən razılaşdırılmalıdır.
- Təkrarlana bilən sübut: hər tapıntıda təsirlənən komponent, ilkin şərt, minimum reproduksiya addımları, təsir və texniki tövsiyə olmalıdır.
- Biznes prioriteti: “kritik” etiketi təkcə CVSS rəqəmi ilə deyil, məlumatın həssaslığı, istismar imkanı, istifadəçi sayı və əməliyyat təsiri ilə əsaslandırılmalıdır.
- Remediasiya yolu: düzəlişin hansı layda ediləcəyi — backend icazə yoxlaması, məlumat modeli, konfiqurasiya, infrastruktur və ya proses — göstərilməlidir.
- Retest: düzəlişdən sonra eyni ssenari yenidən yoxlanılmalı və nəticə “açıq”, “qismən aradan qaldırılıb” və ya “bağlanıb” kimi qeyd edilməlidir.
Audit, penetration test və compliance yoxlaması eyni anlayış deyil. Penetration test müəyyən edilmiş zəifliklərdən istifadə etməklə təsiri nümayiş etdirə bilər. Mühəndislik yönümlü audit isə arxitektura, giriş modelini, release prosesini və uzunmüddətli düzəliş yolunu da araşdırır. Şirkətinizin məqsədi buraxılışdan əvvəl risk azaltmaq və məhsul sahibini aydınlaşdırmaqdırsa, bu ikinci yanaşma daha dəyərli ola bilər.
Auditdən əvvəl şirkət hansı məlumatları hazırlamalıdır?
- Əsas biznes axınlarını seçin: qeydiyyat, sifariş, ödəniş, sənəd yükləmə, hesabat, ixrac, admin əməliyyatları.
- İstifadəçi rollarını və hər rolun görməli olduğu məlumatları siyahıya alın.
- Canlı, test və staging mühitlərini, həmçinin inteqrasiyaları göstərin.
- Test hesabları yaradın: ən azı iki eyni səviyyəli istifadəçi, fərqli rollar və nəzarətli admin hesabı.
- Məlumat məxfiliyi, test vaxtı, əlaqə şəxsi və insident eskalasiyası üzrə yazılı qaydaları razılaşdırın.
- Son dəyişiklikləri paylaşın: yeni API, ödəniş provayderi, SSO, fayl storage, admin modul və ya vendor inteqrasiyası scope-u dəyişə bilər.
Auditdən sonra riskin yenidən yaranmasının qarşısını almaq
Bir dəfə aparılan audit faydalıdır, lakin yeni funksiyalar köhnə icazə sərhədlərini asanlıqla poza bilər. Xüsusən yeni rol, export funksiyası, admin düyməsi, endpoint və ya inteqrasiya əlavə ediləndə authorization matrix-ə uyğun testlərin release pipeline-a daxil edilməsi daha sağlam yanaşmadır. Dəyişiklik qeydləri, təhlükəsizlik jurnalları, dependency yeniləmələri və idarə olunan buraxılış prosesi də eyni dərəcədə vacibdir.
POLADO-nun texniki dəstək və konsaltinq xidməti audit scope-unun hazırlanması, tapıntıların prioritetləşdirilməsi, təhlükəsiz düzəlişlərin tətbiqi və retest planı üçün mühəndislik dəstəyi verə bilər. Platformada arxitektura və ya backend dəyişiklikləri tələb olunarsa, veb platformaların hazırlanması yanaşması ilə mövcud sistemin qorunaraq təkmilləşdirilməsi planlaşdırıla bilər. Həssas rol və məlumat sərhədlərinin real məhsullarda necə düşünülməli olduğunu görmək üçün FT10 və ESFX layihə istiqamətlərinə də baxa bilərsiniz.
Növbəti addım: audit üçün görüşdə tətbiqin istifadəçi rolları, kritik məlumatları, admin funksiyaları, API-ləri və qarşıdakı buraxılışları paylaşın. Bunun əsasında ümumi “skan paketi” deyil, sisteminizin real risk səthinə uyğun test planı, prioritetləndirilmiş remediasiya siyahısı və davamlı application security support modeli müəyyənləşdirilə bilər.