OWASP Mobile Top 10: mi ez, a sebezhetőségek listája és hogyan alkalmazzuk

Mi az OWASP Mobile Top 10?

OWASP Mobile Top 10 a mobilalkalmazásokra jellemző legkritikusabb biztonsági kockázatok szabványosított listája. Az általános OWASP Top 10-től eltérően, amely a webalkalmazásokra vonatkozik, a mobil verzió figyelembe veszi a platformok sajátosságait: helyi tárolás az eszközön, érzékelőkkel való interakció, offline módok és az alkalmazásboltok jellemzői. A dokumentum 2010 óta jelenik meg, és 2–4 évente felülvizsgálják: a 2024-es aktuális verzió olyan kategóriákat tartalmaz, mint az M1 — Improper Credential Usage és az M8 — Security Misconfiguration. A projektet világszerte több mint 500 önkéntesből álló közösség támogatja.

A létrehozás története és célja

Eredetileg az OWASP Top 10 csak a webalkalmazásokra terjedt ki, de a mobilfejlesztés növekedése a 2010-es években külön dokumentumot tett szükségessé. A Mobile Top 10 első verziója 2011-ben jelent meg, és mindössze 7 pontot tartalmazott. 2024-re a lista 10 kategóriára bővült, amelyek mindegyike több konkrét támadási forgatókönyvet foglal magában. A dokumentum fő célja, hogy közös nyelvet adjon a fejlesztőknek és biztonsági csapatoknak a kockázatok megvitatásához és a javítások priorizálásához. A lista rendszeres frissítése tükrözi a fenyegetettségi környezet változásait: új API-k megjelenését, az operációs rendszerek (Android, iOS) fejlődését és a Positive Technologies és más kutatóközpontok jelentéseiben leírt új támadási technikákat.

Hogyan áll össze az OWASP Mobile Top 10 lista

A Mobile Top 10 összeállításának módszertana valós projektek adatain alapul: elemzik a mobilalkalmazások penetrációs tesztjeinek eredményeit, incidensjelentéseket és sebezhetőségi kutatásokat. Minden kategóriát két paraméter alapján értékelnek: előfordulási gyakoriság (Incidence Rate) és potenciális technikai hatás (Technical Impact). E mutatók kombinációja alkotja a végső rangsort. Az szubjektív listákkal ellentétben az OWASP nyílt adatokat használ: a közösség bármely tagja kérelmet nyújthat be új kategória hozzáadására a projekt GitHub-adattárán keresztül. A 2024-es aktuális verzióhoz több mint 300 ezer biztonsági tesztet dolgoztak fel 25 országból, ami reprezentatívvá teszi a statisztikát a mobilfejlesztés globális ökoszisztémájára nézve. Ezenkívül az OWASP közzéteszi a MASVS-t (Mobile Application Security Verification Standard) — a részletes biztonsági követelmények egy készletét, amely több mint 80 konkrét ellenőrzést foglal magában, 8 kategóriába sorolva. A MASVS-t az alkalmazások tanúsításának alapjaként és a penetrációs tesztek ellenőrzőlistájaként használják: minden követelmény hivatkozik a Mobile Top 10 egy kategóriájára, biztosítva a teljes nyomon követhetőséget a szabvány és a kockázati lista között.

A kulcsfontosságú sebezhetőségek áttekintése

Tekintsük át a OWASP Mobile Top 10 2024 három legkritikusabb kategóriáját, amelyek a mobil projektekben előforduló összes biztonsági incidens több mint 70%-át lefedik. Minden kategória konkrét kihasználási forgatókönyveket és védelmi ajánlásokat tartalmaz.

A platform helytelen használata

Ez a kategória (M1) azokat a helyzeteket öleli fel, amikor a fejlesztők az API-kat és platformmechanizmusokat nem rendeltetésszerűen használják. Tipikus példák: Intent Injection Androidon, nyitott Deep Link-kezelők iOS-en, helytelen munka a Keychain és SharedPreferences elemekkel. A támadó egy speciálisan elkészített Intentet küldhet, és hozzáférhet egy másik alkalmazás vagy összetevő adataihoz. A NowSecure (2023) jelentése szerint a tesztelt Android-alkalmazások 22%-a tartalmazott Intent Redirection típusú sebezhetőségeket. A védelem magában foglalja: a bemeneti adatok szigorú érvényesítését, az Intent forrásának ellenőrzését és az engedélyek használatát az exportált összetevőknél.

Nem biztonságos adattárolás

Nem biztonságos adattárolás (M2) a leggyakoribb probléma a mobilalkalmazásokban. Akkor fordul elő, amikor a bizalmas adatokat (hozzáférési tokenek, jelszavak, személyes adatok) nyílt formában vagy elégtelen védelemmel tárolják. A sebezhetőség tipikus forrásai: SQLite-adatbázisok titkosítás nélkül, SharedPreferences EncryptedSharedPreferences nélkül, adatok naplózása debug módban. Az OWASP Foundation (2024) szerint a Google Play ingyenes alkalmazásainak több mint 60%-a tárolja a bizalmas adatok legalább egy típusát titkosítatlan formában. Megoldás — az Android EncryptedSharedPreferences, iOS Keychain használata, valamint az adatok titkosítása a helyi tárolóba írás előtt.

Nem biztonságos kommunikáció

Az M3 kategória — nem biztonságos kommunikáció — az alkalmazás és a szerver közötti adatátviteli csatornák sebezhetőségeit foglalja magában. A HTTPS hiánya, az SSL-tanúsítványok helytelen érvényesítése, az elavult TLS 1.0/1.1 protokollok használata — mindezen problémák lehetővé teszik a támadó számára a forgalom elfogását Man-in-the-Middle támadásokkal. Különösen veszélyes a helyzet, amikor az alkalmazás érzékeny adatokkal (banki tranzakciók, egészségügyi információk) dolgozik egy nem biztonságos csatornán keresztül. 2023-ban az NCC Group kutatói felfedezték, hogy a népszerű pénzügyi alkalmazások 12%-a helytelen TLS-konfigurációt használ. Ajánlás: a HTTPS kötelező használata Certificate Pinninggel és a HTTP elhagyása a production build-ekben.

Alkalmazások tesztelése az OWASP Mobile Top 10 szerint

A mobilalkalmazás biztonságának tesztelése az OWASP módszertana szerint több szakaszt foglal magában: statikus kódelemzés (SAST), dinamikus elemzés (DAST) és manuális tesztelés (pentest). Minden szakasz a Mobile Top 10 bizonyos sebezhetőségi kategóriáinak azonosítására irányul.

Tesztelő eszközök

Az automatizált elemzéshez az OWASP a MobSF (Mobile Security Framework) — egy nyílt forráskódú eszköz használatát ajánlja. A MobSF statikus elemzést végez a forráskódon és a bináris fájlokon, ellenőrzi a manifestumok konfigurációját, elemzi az engedélyeket és azonosítja a Mobile Top 10-ből származó sebezhetőségeket. Dinamikus elemzéshez a Burp Suite (proxy a forgalom elfogásához) és a Frida (runtime-elemző eszköz) használatos. Ezen eszközök kombinációja a lista kategóriáinak több mint 80%-át lefedi. A rendszeres tesztelés a CI/CD-folyamatban a MobSF-fel lehetővé teszi a sebezhetőségek korai felismerését a fejlesztés során, és 60–70%-kal csökkenti a javításuk költségeit. A SAST és DAST eszközök integrálását a folyamatba automatizálni kell Gradle/Maven bővítményeken vagy Fastlane-lépéseken keresztül az iOS buildekben.

A MobSF-jelentés értelmezése

A MobSF futtatása után a fejlesztő egy színes jelzőkkel ellátott jelentést kap: piros — kritikus sebezhetőség, narancs — közepes kockázat, sárga — alacsony. Minden figyelmeztetés tartalmaz egy hivatkozást a megfelelő OWASP Mobile Top 10 kategóriára, a probléma leírását és a javítási javaslatot. Fontos nemcsak a piros figyelmeztetések eltávolítása, hanem a narancssárgák elemzése is: ezek közül sok (pl. exportált Activity védelem nélkül) kombinációban támadási vektort adhat a támadónak. Javasolt a piros figyelmeztetések nulla számának és legfeljebb 2–3 narancssárga figyelmeztetés elérése minden kiadás előtt. A MobSF-jelentés tartalmazza az alkalmazás engedélyeinek elemzését is: minden túlzó engedély (pl. kamerahozzáférés egy számológépben) a minimális jogosultság elvének megsértéseként kerül rögzítésre, és el kell távolítani a manifestumból. iOS-alkalmazások esetében a MobSF hasonló elemzést végez az .ipa-fájlokon, beleértve az Info.plist ellenőrzését ATS-kivételek szempontjából és a Mach-O bináris fájlok elemzését nem biztonságos API-k, például az NSAllowsArbitraryLoads használata szempontjából.

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