OWASP Mobile Top 10: co to jest, lista podatności i jak stosować

Czym jest OWASP Mobile Top 10?

OWASP Mobile Top 10 to standaryzowany wykaz najbardziej krytycznych zagrożeń bezpieczeństwa charakterystycznych właśnie dla aplikacji mobilnych. W przeciwieństwie do ogólnego OWASP Top 10 dla aplikacji webowych, wersja mobilna uwzględnia specyfikę platform: lokalne przechowywanie na urządzeniu, interakcję z czujnikami, tryby offline oraz cechy sklepów z aplikacjami. Dokument publikowany jest od 2010 roku i aktualizowany co 2–4 lata: aktualna wersja na 2024 rok obejmuje takie kategorie jak M1 — Improper Credential Usage i M8 — Security Misconfiguration. Projekt wspierany jest przez społeczność liczącą ponad 500 wolontariuszy na całym świecie.

Historia i cel powstania

Pierwotnie OWASP Top 10 obejmował tylko aplikacje webowe, jednak rozwój aplikacji mobilnych w latach 2010. wymagał osobnego dokumentu. Pierwsza wersja Mobile Top 10 ukazała się w 2011 roku i zawierała zaledwie 7 punktów. Do 2024 roku lista rozszerzyła się do 10 kategorii, z których każda obejmuje kilka konkretnych scenariuszy ataku. Głównym celem dokumentu jest zapewnienie programistom i zespołom bezpieczeństwa wspólnego języka do omawiania zagrożeń i priorytetyzacji poprawek. Regularna aktualizacja listy odzwierciedla zmiany w krajobrazie zagrożeń: pojawianie się nowych API, ewolucję systemów operacyjnych (Android, iOS) i nowe techniki ataków opisane w raportach Positive Technologies i innych ośrodków badawczych.

Jak powstaje lista OWASP Mobile Top 10

Metodologia opracowywania Mobile Top 10 opiera się na danych z rzeczywistych projektów: analizowane są wyniki testów penetracyjnych aplikacji mobilnych, raporty o incydentach i badania podatności. Każda kategoria oceniana jest według dwóch parametrów: częstotliwości występowania (Incidence Rate) i potencjalnego wpływu (Technical Impact). Kombinacja tych wskaźników tworzy ostateczny ranking. W przeciwieństwie do subiektywnych list, OWASP wykorzystuje otwarte dane: każdy członek społeczności może zgłosić wniosek o dodanie nowej kategorii poprzez repozytorium GitHub projektu. Dla aktualnej wersji 2024 przetworzono ponad 300 tysięcy testów bezpieczeństwa z 25 krajów świata, co czyni statystykę reprezentatywną dla globalnego ekosystemu tworzenia aplikacji mobilnych. Dodatkowo OWASP publikuje MASVS (Mobile Application Security Verification Standard) — zestaw szczegółowych wymagań bezpieczeństwa, który obejmuje ponad 80 konkretnych kontroli rozmieszczonych w 8 kategoriach. MASVS jest używany jako podstawa certyfikacji aplikacji i jako lista kontrolna do testów penetracyjnych: każde wymaganie ma odnośnik do kategorii z Mobile Top 10, co zapewnia pełną identyfikowalność między standardem a listą zagrożeń.

Przegląd kluczowych podatności z top listy

Omówmy trzy najbardziej krytyczne kategorie z OWASP Mobile Top 10 2024, które pokrywają ponad 70% wszystkich incydentów bezpieczeństwa w projektach mobilnych. Każda kategoria zawiera konkretne scenariusze wykorzystania i zalecenia dotyczące ochrony.

Nieprawidłowe wykorzystanie platformy

Ta kategoria (M1) obejmuje sytuacje, w których programiści używają API i mechanizmów platformy niezgodnie z przeznaczeniem. Typowe przykłady: Intent Injection na Androidzie, otwarte obsługi Deep Link na iOS, nieprawidłowa praca z Keychain i SharedPreferences. Atakujący może wysłać specjalnie spreparowany Intent i uzyskać dostęp do danych innej aplikacji lub komponentu. Według raportu NowSecure (2023) 22% testowanych aplikacji na Androida zawierało podatności typu Intent Redirection. Ochrona obejmuje: ścisłą walidację danych wejściowych, sprawdzanie źródła Intent oraz używanie uprawnień dla eksportowanych komponentów.

Niebezpieczne przechowywanie danych

Niebezpieczne przechowywanie danych (M2) to najczęściej występujący problem w aplikacjach mobilnych. Pojawia się, gdy poufne dane (tokeny dostępu, hasła, dane osobowe) są przechowywane w otwartej postaci lub z niewystarczającą ochroną. Typowe źródła podatności: bazy SQLite bez szyfrowania, SharedPreferences bez EncryptedSharedPreferences, rejestrowanie danych w trybie debug. Według OWASP Foundation (2024) ponad 60% darmowych aplikacji w Google Play przechowuje co najmniej jeden rodzaj poufnych danych w niezaszyfrowanej postaci. Rozwiązanie — używanie Android EncryptedSharedPreferences, iOS Keychain oraz szyfrowanie danych przed zapisem do lokalnego magazynu.

Niebezpieczna komunikacja

Kategoria M3 — niebezpieczna komunikacja — obejmuje podatności w kanałach transmisji danych między aplikacją a serwerem. Brak HTTPS, nieprawidłowa walidacja certyfikatów SSL, używanie przestarzałych protokołów TLS 1.0/1.1 — wszystkie te problemy umożliwiają atakującemu przechwytywanie ruchu poprzez ataki Man-in-the-Middle. Szczególnie niebezpieczna jest sytuacja, gdy aplikacja pracuje z wrażliwymi danymi (transakcje bankowe, informacje medyczne) przez niezabezpieczony kanał. W 2023 roku badacze z NCC Group odkryli, że 12% popularnych aplikacji finansowych używa nieprawidłowej konfiguracji TLS. Zalecenie: obowiązkowe stosowanie HTTPS z Certificate Pinning i rezygnacja z HTTP w kompilacjach produkcyjnych.

Jak testować aplikacje według OWASP Mobile Top 10

Testowanie bezpieczeństwa aplikacji mobilnej według metodologii OWASP obejmuje kilka etapów: statyczną analizę kodu (SAST), dynamiczną analizę (DAST) i ręczne testowanie (pentest). Każdy etap ma na celu wykrycie określonych kategorii podatności z Mobile Top 10.

Narzędzia do testowania

Do zautomatyzowanej analizy OWASP zaleca używanie MobSF (Mobile Security Framework) — narzędzia z otwartym kodem źródłowym. MobSF wykonuje statyczną analizę kodu źródłowego i plików binarnych, sprawdza konfigurację manifestów, analizuje uprawnienia i wykrywa podatności z Mobile Top 10. Do analizy dynamicznej stosuje się Burp Suite (proxy do przechwytywania ruchu) i Frida (narzędzie do analizy runtime). Połączenie tych narzędzi pokrywa ponad 80% kategorii z listy. Regularne testowanie w potoku CI/CD z MobSF pozwala wykrywać podatności na wczesnych etapach tworzenia i obniża koszt ich naprawy o 60–70%. Wdrożenie narzędzi SAST i DAST w potoku powinno być zautomatyzowane poprzez wtyczki Gradle/Maven lub kroki Fastlane w kompilacjach iOS.

Interpretacja raportu MobSF

Po uruchomieniu MobSF programista otrzymuje raport z kolorowymi oznaczeniami: czerwony — podatność krytyczna, pomarańczowy — średnie ryzyko, żółty — niskie. Każde ostrzeżenie zawiera odnośnik do odpowiedniej kategorii OWASP Mobile Top 10, opis problemu i zalecenie naprawy. Ważne jest nie tylko usunięcie czerwonych ostrzeżeń, ale także analiza pomarańczowych: wiele z nich (np. eksportowane Activity bez zabezpieczenia) w połączeniu może dać atakującemu wektor ataku. Zaleca się dążenie do zerowej liczby czerwonych ostrzeżeń i nie więcej niż 2–3 pomarańczowych przed każdym wydaniem. Raport MobSF zawiera również analizę uprawnień aplikacji: wszelkie nadmiarowe uprawnienia (np. dostęp do kamery w kalkulatorze) są oznaczane jako naruszenie zasady minimalnych uprawnień i powinny zostać usunięte z manifestu. Dla aplikacji iOS MobSF wykonuje analogiczną analizę plików .ipa, w tym sprawdzanie Info.plist pod kątem wyjątków ATS oraz analizę plików binarnych Mach-O pod kątem użycia niebezpiecznych API, takich jak NSAllowsArbitraryLoads.

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()
    }
}