OWASP Mobile Top 10: wat het is, lijst met kwetsbaarheden en hoe toe te passen

Wat is OWASP Mobile Top 10?

OWASP Mobile Top 10 is een gestandaardiseerde lijst van de meest kritieke beveiligingsrisico's die specifiek zijn voor mobiele applicaties. In tegenstelling tot de algemene OWASP Top 10 voor webapplicaties houdt de mobiele versie rekening met de specifieke kenmerken van platforms: lokale opslag op het apparaat, interactie met sensoren, offline modi en kenmerken van app-winkels. Het document wordt sinds 2010 gepubliceerd en wordt elke 2–4 jaar herzien: de huidige versie voor 2024 bevat categorieën zoals M1 — Improper Credential Usage en M8 — Security Misconfiguration. Het project wordt ondersteund door een gemeenschap van meer dan 500 vrijwilligers wereldwijd.

Geschiedenis en doel van oprichting

Oorspronkelijk omvatte OWASP Top 10 alleen webapplicaties, maar de groei van mobiele ontwikkeling in de jaren 2010 vereiste een apart document. De eerste versie van Mobile Top 10 verscheen in 2011 en bevatte slechts 7 punten. Tegen 2024 is de lijst uitgebreid tot 10 categorieën, die elk verschillende specifieke aanvalsscenario's omvatten. Het belangrijkste doel van het document is om ontwikkelaars en beveiligingsteams een gemeenschappelijke taal te geven om risico's te bespreken en oplossingen te prioriteren. Regelmatige bijwerking van de lijst weerspiegelt veranderingen in het bedreigingslandschap: de opkomst van nieuwe API's, de evolutie van besturingssystemen (Android, iOS) en nieuwe aanvalstechnieken beschreven in rapporten van Positive Technologies en andere onderzoekscentra.

Hoe de OWASP Mobile Top 10-lijst wordt samengesteld

De methodologie voor het opstellen van Mobile Top 10 is gebaseerd op gegevens uit echte projecten: resultaten van penetratietests van mobiele apps, incidentrapporten en kwetsbaarheidsonderzoeken worden geanalyseerd. Elke categorie wordt beoordeeld op twee parameters: frequentie van voorkomen (Incidence Rate) en potentiële technische impact (Technical Impact). De combinatie van deze metrieken vormt de uiteindelijke ranglijst. In tegenstelling tot subjectieve lijsten gebruikt OWASP open data: elk lid van de gemeenschap kan een verzoek indienen om een nieuwe categorie toe te voegen via de GitHub-repository van het project. Voor de huidige versie van 2024 zijn meer dan 300 duizend beveiligingstests uit 25 landen verwerkt, wat de statistiek representatief maakt voor het wereldwijde ecosysteem van mobiele ontwikkeling. Daarnaast publiceert OWASP MASVS (Mobile Application Security Verification Standard) — een set gedetailleerde beveiligingseisen die meer dan 80 specifieke controles omvat, verdeeld over 8 categorieën. MASVS wordt gebruikt als basis voor certificering van apps en als checklist voor penetratietests: elke eis verwijst naar een categorie uit Mobile Top 10, wat volledige traceerbaarheid tussen de standaard en de risicolijst garandeert.

Overzicht van de belangrijkste kwetsbaarheden

Laten we de drie meest kritieke categorieën uit OWASP Mobile Top 10 2024 bekijken, die meer dan 70% van alle beveiligingsincidenten in mobiele projecten dekken. Elke categorie bevat specifieke exploitscenario's en beschermingsaanbevelingen.

Onjuist gebruik van het platform

Deze categorie (M1) omvat situaties waarin ontwikkelaars API's en platformmechanismen niet volgens hun doel gebruiken. Typische voorbeelden: Intent Injection op Android, open Deep Link-handlers op iOS, onjuist werken met Keychain en SharedPreferences. Een aanvaller kan een speciaal geconstrueerde Intent sturen en toegang krijgen tot gegevens van een andere app of component. Volgens het NowSecure-rapport (2023) bevatte 22% van de geteste Android-apps Intent Redirection-kwetsbaarheden. Bescherming omvat: strikte validatie van invoergegevens, controle van de Intent-bron en het gebruik van machtigingen voor geëxporteerde componenten.

Onveilige gegevensopslag

Onveilige gegevensopslag (M2) is het meest voorkomende probleem in mobiele apps. Het ontstaat wanneer vertrouwelijke gegevens (toegangstokens, wachtwoorden, persoonlijke gegevens) in open vorm of met onvoldoende bescherming worden opgeslagen. Typische bronnen van kwetsbaarheid: SQLite-databases zonder versleuteling, SharedPreferences zonder EncryptedSharedPreferences, het loggen van gegevens in debug-modus. Volgens OWASP Foundation (2024) slaat meer dan 60% van de gratis apps in Google Play ten minste één type vertrouwelijke gegevens op in ongecodeerde vorm. Oplossing — gebruik van Android EncryptedSharedPreferences, iOS Keychain en versleuteling van gegevens voordat ze naar lokale opslag worden geschreven.

Onveilige communicatie

Categorie M3 — onveilige communicatie — omvat kwetsbaarheden in de gegevensoverdrachtkanalen tussen de app en de server. Het ontbreken van HTTPS, onjuiste validatie van SSL-certificaten, het gebruik van verouderde TLS 1.0/1.1-protocollen — al deze problemen stellen een aanvaller in staat verkeer te onderscheppen via Man-in-the-Middle-aanvallen. De situatie is bijzonder gevaarlijk wanneer de app met gevoelige gegevens (banktransacties, medische informatie) werkt via een onbeveiligd kanaal. In 2023 ontdekten onderzoekers van NCC Group dat 12% van de populaire financiële apps een onjuiste TLS-configuratie gebruikt. Aanbeveling: verplicht gebruik van HTTPS met Certificate Pinning en afzien van HTTP in productiebuilds.

Apps testen volgens OWASP Mobile Top 10

Het testen van de beveiliging van een mobiele app volgens de OWASP-methodologie omvat verschillende fasen: statische code-analyse (SAST), dynamische analyse (DAST) en handmatig testen (pentest). Elke fase is gericht op het identificeren van bepaalde categorieën kwetsbaarheden uit Mobile Top 10.

Testtools

Voor geautomatiseerde analyse beveelt OWASP het gebruik van MobSF (Mobile Security Framework) aan — een open-source tool. MobSF voert statische analyse van broncode en binaire bestanden uit, controleert de manifestconfiguratie, analyseert machtigingen en identificeert kwetsbaarheden uit Mobile Top 10. Voor dynamische analyse worden Burp Suite (proxy voor verkeersonderschepping) en Frida (tool voor runtime-analyse) gebruikt. De combinatie van deze tools dekt meer dan 80% van de categorieën op de lijst. Regelmatig testen in de CI/CD-pijplijn met MobSF maakt het mogelijk kwetsbaarheden in een vroeg stadium van de ontwikkeling te identificeren en verlaagt de kosten van het oplossen ervan met 60–70%. Integratie van SAST- en DAST-tools in de pijplijn moet worden geautomatiseerd via Gradle/Maven-plugins of Fastlane-stappen in iOS-builds.

Interpretatie van het MobSF-rapport

Na het uitvoeren van MobSF krijgt de ontwikkelaar een rapport met kleurindicatoren: rood — kritieke kwetsbaarheid, oranje — gemiddeld risico, geel — laag. Elke waarschuwing bevat een verwijzing naar de corresponderende OWASP Mobile Top 10-categorie, een beschrijving van het probleem en een aanbeveling voor oplossing. Het is belangrijk niet alleen de rode waarschuwingen te verwijderen, maar ook de oranje te analyseren: veel daarvan (bijvoorbeeld geëxporteerde Activity zonder bescherming) kunnen in combinatie een aanvalsvector bieden aan een aanvaller. Het wordt aanbevolen om een nul aantal rode waarschuwingen en niet meer dan 2–3 oranje waarschuwingen te bereiken vóór elke release. Het MobSF-rapport bevat ook een analyse van app-machtigingen: alle overbodige machtigingen (bijvoorbeeld cameratoegang in een rekenmachine) worden geregistreerd als schending van het principe van minimale privileges en moeten uit het manifest worden verwijderd. Voor iOS-apps voert MobSF een vergelijkbare analyse van .ipa-bestanden uit, inclusief controle van Info.plist op ATS-uitzonderingen en analyse van Mach-O-binaire bestanden op het gebruik van onveilige API's zoals 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()
    }
}