Mobiele applicaties
Pentest voor mobiele applicaties (iOS en Android)
Uw mobiele applicatie draait op een toestel dat u niet beheert. Een aanvaller krijgt daardoor het installatiebestand, de opslag op het toestel en al het verkeer in handen. Wij testen die drie lagen, plus de backend waarmee de app praat.
Zo'n penetratietest volgt de verificatiestandaard OWASP MASVS en de testhandleiding MASTG. Daardoor is de dekking meetbaar en hangt het resultaat niet af van wie de app toevallig heeft getest.
Zij vertrouwen op ons
Mobiele applicaties
Wat wij testen op iOS en Android
Een pentest van een mobiele applicatie gaat veel verder dan de schermen die de gebruiker ziet. Wij werken op een echt toestel met dezelfde build die in de App Store en Google Play staat: wij decompileren de app, instrumenteren waar nodig het draaiende proces en lopen elke route na die openstaat voor een aanvaller met een gestolen telefoon of een toestel met root- of jailbreakrechten.
Is de app een dunne schil over uw API, dan zit het echte risico bijna altijd achter die API: het sessietoken staat op het toestel, maar aan de serverkant controleert niemand de autorisatie. Daarom nemen wij de backend mee in de scope.
Dekking per MASVS-categorie
| Gebied | Waar wij naar kijken |
|---|---|
| Gegevensopslag | Sleutels en tokens in SharedPreferences of UserDefaults, onversleutelde databases op het toestel, persoonsgegevens in externe opslag en gegevens die in back-ups blijven staan. |
| Dataverkeer | Verkeer in platte tekst, certificaten die niet worden gecontroleerd en TLS-pinning die tijdens het draaien te omzeilen is. |
| Inloggegevens en sessies | API-sleutels in de code, tokens die in logbestanden belanden, sessietokens die opnieuw te gebruiken zijn en biometrische bevestiging die niets afschermt. |
| Bescherming van de app zelf | Een releasebuild waarin debugging aanstaat, ontbrekende detectie van root en jailbreak en zwakke bescherming tegen herverpakken en manipulatie. |
| Platformkoppelingen | Geëxporteerde componenten, misbruik van deeplinks, JavaScript-bruggen in WebViews en path traversal in content providers. |
| Toeleveringsketen | SDK's met kwaadaardige code, dependency confusion en het laden van niet-ondertekende code tijdens het draaien. |
Elke regel verwijst naar het bijbehorende hoofdstuk in de Haxoris Wiki (in het Engels): daar beschrijven wij de zwakke plek, hoe een aanvaller die misbruikt en hoe u die verhelpt.
Hoe verloopt een pentest van een mobiele applicatie?
Voor een gemiddelde app duurt het traject twee tot vier weken, inclusief de hertest.
Scope bepalen
Wij spreken de platforms af, de build, de testaccounts en of de backend in scope zit. U krijgt een vaste prijs voordat er iets begint. Wij testen uitsluitend op basis van een schriftelijke opdracht en binnen de afgesproken scope.
Statische analyse
Wij decompileren de build, lezen het manifest en de entitlements en zoeken naar achtergelaten sleutels, zwakke cryptografie en debugresten in de release.
Dynamisch testen
Op een echt toestel: instrumentatie tijdens het draaien, verkeer onderscheppen, pinning omzeilen, de opslag doorlopen en geëxporteerde interfaces misbruiken.
Backend en API
De API's waarvan de app afhankelijk is, testen wij net zo grondig als een webapplicatie: autorisatie, IDOR, rate limiting en bedrijfslogica.
Rapport en hertest
Elke bevinding krijgt bewijs en een concreet hersteladvies. Zodra de fixes live staan, testen wij ze kosteloos opnieuw.
Wat levert het op?
Bij elke pentest van een mobiele applicatie hoort:
Klantervaringen
Wat klanten over ons zeggen
Pentest voor mobiele applicaties – veelgestelde vragen
01 Hebben jullie de broncode nodig?
Nee. Standaard testen wij black box op de release die in de store staat. Kunt u broncode of een debugbuild delen, dan gebruiken wij die: grey box levert in hetzelfde aantal dagen meer bevindingen op. Verplicht is het niet. Is de app door een externe partij gebouwd en komt u zelf niet bij de code, dan verandert dat niets aan de aanpak.
02 Testen jullie zowel iOS als Android?
Ja. De meeste klanten laten beide platforms testen, omdat ze anders falen: Android lekt vaker via geëxporteerde componenten en de opslag op het toestel, iOS via verkeerd gebruik van de Keychain en jailbreakdetectie die te omzeilen is.
03 Zit de backend-API in de scope?
Dat kan, en meestal is het verstandig. Een mobiele applicatie is vaak een dunne schil over een API waar de echte autorisatielogica draait. Wij leggen de scope vooraf schriftelijk vast, zodat achteraf niet ter discussie staat wat wel en niet is getest.
04 Hoe vaak moet een mobiele applicatie getest worden?
Twee dingen bepalen het ritme. Verwerkt de app persoonsgegevens, dan vraagt de AVG (artikel 32 lid 1 sub d) waar passend om 'een procedure voor het op gezette tijdstippen testen, beoordelen en evalueren van de doeltreffendheid' van uw beveiligingsmaatregelen. Dat is de duidelijkste Europese grondslag voor periodiek testen. De Cyberbeveiligingswet noemt pentesten niet: die vraagt om een risicoanalyse en om passende en evenredige maatregelen, en een pentest is de gebruikelijke manier om aan te tonen dat die maatregelen werken. Financiële entiteiten vallen buiten die wet (artikel 7); voor hen geldt DORA. Daarnaast telt uw releaseritme: verschijnt er elke maand een nieuwe versie, koppel de test dan aan de grote functionele wijzigingen. Een pentest is een technische toets, geen juridisch oordeel over welke regels op uw organisatie van toepassing zijn.
05 Wat kost een pentest van een mobiele applicatie?
De prijs volgt de scope: het aantal platforms, de omvang en complexiteit van de app, of er betalingen in zitten en of de backend meegaat. Eén platform begint rond € 2.000. Voor beide platforms samen met de backend rekent u op 8 tot 15 mandagen. Na een kort gesprek over de scope krijgt u een vaste prijs voor het hele traject, hertest inbegrepen.
06 Kunnen jullie een app testen die nog niet gepubliceerd is?
Ja, en dat is het beste moment. Stuur een ondertekende build: TestFlight, een APK of toegang tot een intern distributiekanaal. Dan testen wij de app voordat uw gebruikers hem in handen krijgen.
