Mobilalkalmazások
Mobilalkalmazás penetrációs teszt – Android és iOS
A mobilalkalmazás olyan készüléken fut, amelyet már nem Ön felügyel: a támadó kezébe kerül a bináris, a helyben tárolt adat és a teljes hálózati forgalom. Mind a hármat megvizsgáljuk – és velük együtt azt a backendet is, amelyhez az alkalmazás csatlakozik.
Az OWASP MASVS ellenőrzési szabvány és az MASTG tesztelési útmutató szerint dolgozunk. Így a lefedettség mérhető marad, és nem azon múlik, ki végezte éppen a tesztet.
Ők bíznak bennünk
Mobilalkalmazások
Mit vizsgálunk az Android- és iOS-alkalmazásokban?
A felhasználói felület csak a mobilalkalmazás felszíne. Valódi készüléken és valódi buildből dolgozunk: visszafejtjük a kódot, szükség esetén belenyúlunk a futó alkalmazásba, és végigmegyünk minden támadási úton, amely egy ellopott vagy rootolt telefonról nyitva áll.
Ha az alkalmazás csak vékonykliens, a valódi kockázat a mögötte álló API-ban van – ezért az API-t is bevesszük a hatókörbe.
Lefedettség MASVS-kategóriák szerint
| Terület | Tipikus hibák |
|---|---|
| Adattárolás | Jelszavak és tokenek a SharedPreferences tárolóban, titkosítatlan adatbázis, érzékeny adat a külső tárhelyen, biztonsági mentésbe átkerülő adat. |
| Adatátvitel | Titkosítatlan forgalom, hiányzó tanúsítványellenőrzés, futásidőben megkerülhető TLS-pinning. |
| Hitelesítő adatok és munkamenetek | Beégetett API-kulcsok, naplóba kiírt tokenek, újrajátszható munkamenet-azonosítók, biometrikus ellenőrzés, amely mögött nincs valódi védelem. |
| Bináris védelem | Hibakeresésre nyitva hagyott éles build, root- és jailbreak-felismerés nélkül futó alkalmazás, újracsomagolás és kódmódosítás elleni gyenge védelem. |
| Rendszerinterfészek | Exportált komponensek, visszaélés a deeplinkekkel, WebView JavaScript-hidak, path traversal a content providerekben. |
| Ellátási lánc | Kártékony kóddal fertőzött SDK-k, dependency confusion, aláíratlan kód futásidejű betöltése. |
Minden sor a Haxoris Wiki megfelelő fejezetére mutat (angolul): ott leírjuk, mi a hiba, hogyan használható ki, és hogyan javítható.
Hogyan zajlik egy mobilalkalmazás vizsgálata?
Egy átlagos alkalmazás vizsgálata két-négy hét, az újrateszteléssel együtt.
Hatókör
Megállapodunk a platformokról, a buildről, a tesztfiókokról és arról is, hogy a backend beletartozik-e. Fix árat kap, mielőtt bármi elindul.
Statikus elemzés
Visszafejtjük a buildet, átnézzük a manifestet és a jogosultságokat, és megkeressük a beégetett kulcsokat, a gyenge titkosítást és az éles változatban felejtett hibakeresési maradványokat.
Dinamikus tesztelés
Valódi készüléken dolgozunk: futás közben módosítjuk az alkalmazás működését, elfogjuk a forgalmat, megkerüljük a pinninget, belenézünk a helyben tárolt adatokba, és visszaélünk az exportált interfészekkel.
Backend és API
Az API-kat, amelyekre az alkalmazás támaszkodik, ugyanolyan alaposan vizsgáljuk, mint egy webalkalmazást: jogosultságkezelés, IDOR, kérésszám-korlátozás, üzleti logika.
Jelentés és újratesztelés
Minden megállapítás mellé bizonyítékot és javítási javaslatot adunk. Amint kijavította a hibákat, ingyen újratesztelünk.
Mit kap a munka végén?
Minden mobilalkalmazás-vizsgálat tartalmazza a következőket:
Ügyfélvélemények
Mit mondanak rólunk ügyfeleink
Mobilalkalmazás penetrációs tesztje – gyakori kérdések
01 Kell hozzá forráskód?
Nincs rá szükség. Alapesetben black-box módszerrel, az éles buildből dolgozunk. Ha meg tudja osztani a forráskódot vagy egy debug buildet, azt is felhasználjuk – grey-box vizsgálattal ugyanannyi nap alatt több hibát találunk –, de nem feltétel.
02 Vizsgálni kell-e az iOS- és az Android-változatot is?
Érdemes. A két platform másképp romlik el: Androidon többnyire az exportált komponenseken és a helyi tárolón keresztül szivárog az adat, az iOS-változatban a keychain hibás használata és a megkerülhető jailbreak-felismerés a jellemző hiba. Az ügyfeleink többsége ezért mindkét változatot megrendeli.
03 Bele kell-e venni a backend API-t a vizsgálatba?
Általában igen. A mobilalkalmazás sokszor csak vékonykliens, és a valódi jogosultságkezelés az API-ban van. A hatókört ezért írásban rögzítjük, hogy a vizsgálat után ne legyen kérdés, mit néztünk meg és mit nem.
04 Milyen gyakran kell mobilalkalmazást vizsgálni?
Ágazattól függ. A pénzügyi szektorban a Magyar Nemzeti Bank 1/2025. (I. 13.) számú ajánlása ad támpontot: a 13.1.4 e) pont szerint a mobilalkalmazások abba a körbe tartoznak, ahol negyedévente kell sérülékenységvizsgálatot végezni. Ugyanez az ajánlás az internet felől elérhető alkalmazásoknál penetrációs tesztet vár el: élesítés előtt, minden biztonságot érintő változtatás után, majd legalább évente egyszer. Az MNB ajánlása nem jogszabály, hanem felügyeleti elvárás. Máshol a kiadási ütem dönt: aki havonta ad ki új verziót, annak a nagyobb funkcionális változásokhoz érdemes kötnie a vizsgálatot.
05 Mennyibe kerül egy mobilalkalmazás penetrációs tesztje?
Attól függ, hány platform és milyen backend tartozik a hatókörbe. Két platform a mögöttes API-val együtt jellemzően 8–15 szakértői nap. A hatókör tisztázása után fix árat adunk.
06 Tesztelhető-e egy még meg nem jelent alkalmazás?
Igen, és ez a jobbik időpont. Küldjön egy aláírt buildet – TestFlight, APK vagy belső terjesztési csatorna –, és megvizsgáljuk, mielőtt a felhasználókhoz kerül.
