Mobiele apps worden vaak behandeld als een extra kanaal naast de “echte” webapplicatie, en dat vertaalt zich regelmatig naar minder aandacht voor beveiliging. Terecht is dat niet: een mobiele app draait grotendeels op een apparaat dat je niet beheert, communiceert met dezelfde backend als je webapplicatie, en introduceert daarmee een eigen set risico’s die een reguliere webapplicatie-pentest niet dekt.

Waarom een mobiele app anders getest moet worden

Bij een webapplicatie draait de code op een server die jij beheert. Bij een mobiele app draait een deel van de logica letterlijk op het toestel van de gebruiker, inclusief eventuele API-sleutels, encryptie-implementaties en lokale opslag. Een aanvaller met fysieke of root/jailbreak-toegang tot een toestel kan de app decompileren, verkeer onderscheppen en lokale opslag uitlezen, dingen die bij een puur server-side applicatie simpelweg niet mogelijk zijn.

Voor zowel iOS als Android gelden hierbij platformspecifieke aandachtspunten: op iOS onder meer de Keychain, App Transport Security en binary-protecties; op Android onder meer de manier waarop permissies worden afgedwongen, hoe gevoelige data in SharedPreferences of lokale databases wordt opgeslagen, en de robuustheid tegen reverse engineering van de APK.

Wat een gedegen mobiele pentest onderzoekt

Lokale opslag: staan wachtwoorden, tokens of persoonsgegevens onversleuteld op het toestel?
Communicatie met de backend: is certificate pinning geïmplementeerd, en is verkeer te onderscheppen met een proxy zoals Burp Suite?
Authenticatie en sessiebeheer: blijven tokens geldig na uitloggen, en zijn ze voldoende kort-levend?
Reverse engineering-weerstand: hoe makkelijk is de app te decompileren, en staan er hardcoded secrets in de code?
Backend-API’s: vrijwel elke mobiele app praat met dezelfde of vergelijkbare API’s als de webapplicatie, en verdient dus ook een volwaardige API pentest als onderdeel van de scope.

Veelgemaakte aanname: “de App Store/Play Store screent dit al”

Apple en Google controleren apps voornamelijk op malware, beleid en basale functionaliteit, niet op applicatiebeveiliging in de diepte. Een app die keurig door de review-processen komt, kan nog altijd gevoelige data onversleuteld opslaan of een backend hebben die autorisatie niet goed afdwingt. Store-goedkeuring is geen beveiligingskeurmerk.

Wanneer een mobiele pentest het meest oplevert

Het grootste rendement zit in testen vóór een grote release, met name wanneer er nieuwe functionaliteit bijkomt rond authenticatie, betalingen of het opslaan van gevoelige gegevens. Voor apps die veel persoonsgegevens of financiële data verwerken is een jaarlijkse test, net als bij een reguliere webapplicatie pentest, een redelijk uitgangspunt, aangevuld met een hertest na ingrijpende wijzigingen.

Een voorbeeld uit de praktijk

Bij een decompilatie van een Android-app die keurig door de Play Store-review was gekomen, bleek de API-sleutel voor een derde-partij-dienst gewoon als platte tekst in de code te staan, duidelijk leesbaar na het uitpakken van de APK met gratis, vrij verkrijgbare tooling. Die sleutel gaf toegang tot een dienst die ver buiten de intentie van de app lag. De app zelf werkte feilloos, de store-review zag niets vreemds, en toch lag er een directe route naar misbruik, precies het soort bevinding dat alleen aan het licht komt door de app daadwerkelijk te decompileren in plaats van hem alleen te gebruiken zoals bedoeld.

Hoe MonkeysICT mobiele apps test

We testen zowel de app zelf (statische en dynamische analyse, op een echt toestel) als de backend waarmee hij praat, zodat je niet alleen weet of de app veilig is, maar of de hele keten dat is. Het rapport maakt onderscheid tussen platformspecifieke bevindingen (iOS versus Android) en bevindingen die in de backend zitten en dus voor beide platforms gelden.