OWASP Mobile Top 10: bu nədir, zəifliklərin siyahısı və necə tətbiq edilir

OWASP Mobile Top 10 nədir?

OWASP Mobile Top 10 — məhz mobil tətbiqlər üçün xarakterik olan ən kritik təhlükəsizlik risklərinin standartlaşdırılmış siyahısıdır. Veb tətbiqlər üçün ümumi OWASP Top 10-dan fərqli olaraq, mobil versiya platformaların spesifikasını nəzərə alır: cihazda yerli saxlama, sensorlarla qarşılıqlı əlaqə, oflayn rejimlər və tətbiq mağazalarının xüsusiyyətləri. Sənəd 2010-cu ildən dərc olunur və hər 2–4 ildən bir yenidən nəzərdən keçirilir: 2024-cü il üçün aktual versiyaya M1 — Improper Credential Usage və M8 — Security Misconfiguration kimi kateqoriyalar daxildir. Layihə bütün dünyada 500-dən çox könüllüdən ibarət icma tərəfindən dəstəklənir.

Yaranma tarixi və məqsədi

Əslində OWASP Top 10 yalnız veb tətbiqləri əhatə edirdi, lakin 2010-cu illərdə mobil inkişafın artması ayrıca sənəd tələb etdi. Mobile Top 10-un ilk versiyası 2011-ci ildə çıxdı və cəmi 7 bənddən ibarət idi. 2024-cü ilə qədər siyahı 10 kateqoriyaya qədər genişləndi, hər biri bir neçə konkret hücum ssenarisini əhatə edir. Sənədin əsas məqsədi tərtibatçılara və təhlükəsizlik komandalarına riskləri müzakirə etmək və düzəlişləri prioritetləşdirmək üçün vahid dil təmin etməkdir. Siyahının müntəzəm yenilənməsi təhdid mənzərəsindəki dəyişiklikləri əks etdirir: yeni API-lərin meydana çıxması, əməliyyat sistemlərinin (Android, iOS) təkamülü və Positive Technologies və digər tədqiqat mərkəzlərinin hesabatlarında təsvir edilən yeni hücum texnikaları.

OWASP Mobile Top 10 siyahısı necə formalaşır

Mobile Top 10-un tərtib edilməsi metodologiyası real layihələrdən alınan məlumatlara əsaslanır: mobil tətbiqlərin penetrasiya testlərinin nəticələri, insident hesabatları və zəiflik tədqiqatları təhlil edilir. Hər bir kateqoriya iki parametr üzrə qiymətləndirilir: rastgəlmə tezliyi (Incidence Rate) və potensial zərər (Technical Impact). Bu göstəricilərin kombinasiyası yekun reytinqi formalaşdırır. Subyektiv siyahılardan fərqli olaraq, OWASP açıq məlumatlardan istifadə edir: icmanın istənilən üzvü GitHub repo layihəsi vasitəsilə yeni kateqoriyanın əlavə edilməsi üçün müraciət edə bilər. 2024-cü ilin aktual versiyası üçün dünyanın 25 ölkəsindən 300 mindən çox təhlükəsizlik testi emal edilib ki, bu da statistikaları mobil inkişafın qlobal ekosistemi üçün reprezentativ edir. Əlavə olaraq, OWASP MASVS (Mobile Application Security Verification Standard) — 8 kateqoriya üzrə bölüşdürülmüş 80-dən çox konkret yoxlamanı özündə birləşdirən təhlükəsizlik tələbləri dəstini dərc edir. MASVS tətbiqlərin sertifikatlaşdırılması üçün baza və penetrasiya testləri üçün yoxlama siyahısı kimi istifadə olunur: hər bir tələb Mobile Top 10-dan kateqoriyaya istinad edir ki, bu da standart və risk siyahısı arasında tam izlənməni təmin edir.

Əsas zəifliklərin icmalı

OWASP Mobile Top 10 2024-dən mobil layihələrdə bütün təhlükəsizlik insidentlərinin 70%-dən çoxunu əhatə edən üç ən kritik kateqoriyanı nəzərdən keçirək. Hər bir kateqoriya konkret istismar ssenariləri və müdafiə tövsiyələrini ehtiva edir.

Platformanın düzgün istifadə edilməməsi

Bu kateqoriya (M1) tərtibatçıların API və platforma mexanizmlərindən təyinatı üzrə istifadə etmədiyi vəziyyətləri əhatə edir. Tipik nümunələr: Android-də Intent Injection, iOS-da açıq Deep Link işləyiciləri, Keychain və SharedPreferences ilə yanlış iş. Təcavüzkar xüsusi hazırlanmış Intent göndərə və başqa tətbiqin və ya komponentin məlumatlarına giriş əldə edə bilər. NowSecure (2023) hesabatına görə, test edilmiş Android tətbiqlərinin 22%-i Intent Redirection tipli zəifliklər ehtiva edirdi. Müdafiə daxildir: giriş məlumatlarının ciddi validasiyası, Intent mənbəyinin yoxlanılması və ixrac edilən komponentlər üçün icazələrin istifadəsi.

Təhlükəsiz olmayan məlumat saxlanması

Təhlükəsiz olmayan məlumat saxlanması (M2) mobil tətbiqlərdə ən geniş yayılmış problemdir. Məxfi məlumatlar (giriş tokenləri, şifrələr, şəxsi məlumatlar) açıq formada və ya kifayət qədər qorunmadan saxlandıqda yaranır. Zəifliyin tipik mənbələri: şifrələnməmiş SQLite verilənlər bazaları, EncryptedSharedPreferences olmadan SharedPreferences, debug rejimində məlumatların jurnallaşdırılması. OWASP Foundation (2024) məlumatına görə, Google Play-dəki pulsuz tətbiqlərin 60%-dən çoxu ən azı bir növ məxfi məlumatı şifrələnməmiş formada saxlayır. Həll — Android EncryptedSharedPreferences, iOS Keychain istifadəsi və yerli yaddaşa yazmadan əvvəl məlumatların şifrələnməsi.

Təhlükəsiz olmayan kommunikasiya

M3 kateqoriyası — təhlükəsiz olmayan kommunikasiya — tətbiq və server arasında məlumat ötürmə kanallarında zəiflikləri əhatə edir. HTTPS-nin olmaması, SSL sertifikatlarının yanlış validasiyası, köhnəlmiş TLS 1.0/1.1 protokollarının istifadəsi — bütün bu problemlər təcavüzkara Man-in-the-Middle hücumları vasitəsilə trafiki ələ keçirməyə imkan verir. Tətbiq qorunmayan kanal vasitəsilə həssas məlumatlarla (bank əməliyyatları, tibbi məlumat) işlədikdə vəziyyət xüsusilə təhlükəlidir. 2023-cü ildə NCC Group tədqiqatçıları məşhur maliyyə tətbiqlərinin 12%-nin yanlış TLS konfiqurasiyasından istifadə etdiyini aşkar etdilər. Tövsiyə: Certificate Pinning ilə HTTPS-in məcburi istifadəsi və istehsal qurğularında HTTP-dən imtina.

OWASP Mobile Top 10-a uyğun tətbiqləri necə test etməli

Mobil tətbiqin təhlükəsizliyinin OWASP metodologiyası üzrə test edilməsi bir neçə mərhələni əhatə edir: statik kod analizi (SAST), dinamik analiz (DAST) və əl ilə test (pentest). Hər bir mərhələ Mobile Top 10-dan müəyyən zəiflik kateqoriyalarını aşkar etməyə yönəlmişdir.

Test alətləri

Avtomatlaşdırılmış analiz üçün OWASP MobSF (Mobile Security Framework) — açıq mənbə alətindən istifadə etməyi tövsiyə edir. MobSF mənbə kodu və binar faylların statik analizini aparır, manifest konfiqurasiyasını yoxlayır, icazələri təhlil edir və Mobile Top 10-dan zəiflikləri aşkar edir. Dinamik analiz üçün Burp Suite (trafik ələ keçirmə proksi) və Frida (runtime analiz aləti) istifadə olunur. Bu alətlərin kombinasiyası siyahıdakı kateqoriyaların 80%-dən çoxunu əhatə edir. CI/CD konveyerində MobSF ilə müntəzəm test zəiflikləri inkişafın erkən mərhələlərində aşkar etməyə imkan verir və onların düzəldilmə xərclərini 60–70% azaldır. SAST və DAST alətlərinin konveyerə inteqrasiyası Gradle/Maven plaginləri və ya iOS qurğularında Fastlane addımları vasitəsilə avtomatlaşdırılmalıdır.

MobSF hesabatının interpretasiyası

MobSF-i işə saldıqdan sonra tərtibatçı rəng göstəriciləri olan hesabat alır: qırmızı — kritik zəiflik, narıncı — orta risk, sarı — aşağı. Hər bir xəbərdarlıq müvafiq OWASP Mobile Top 10 kateqoriyasına keçid, problem təsviri və düzəliş tövsiyəsi ehtiva edir. Təkcə qırmızı xəbərdarlıqları aradan qaldırmaq deyil, həm də narıncı olanları təhlil etmək vacibdir: onların bir çoxu (məsələn, qorunmayan ixrac edilmiş Activity) kombinasiyada təcavüzkara hücum vektoru verə bilər. Hər buraxılışdan əvvəl qırmızı xəbərdarlıqların sıfır sayına və 2–3-dən çox olmayan narıncı xəbərdarlığa nail olmaq tövsiyə olunur. MobSF hesabatı həmçinin tətbiq icazələrinin təhlilini əhatə edir: hər hansı artıq icazə (məsələn, kalkulyatorda kameraya giriş) minimum imtiyaz prinsipinin pozulması kimi qeyd olunur və manifestdən silinməlidir. iOS tətbiqləri üçün MobSF .ipa fayllarının analoji təhlilini aparır, o cümlədən ATS istisnaları üçün Info.plist-in yoxlanılması və NSAllowsArbitraryLoads kimi təhlükəsiz olmayan API-lərin istifadəsi üçün Mach-O binar fayllarının təhlili.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}