Penetrační testování mobilních aplikací

Test stojí na dvou přístupech, statické a dynamické analýze. Statická znamená rozebrání buildu bez spuštění: u Androidu dekompilaci APK, u iOS rozbor IPA, hledání natvrdo zadaných klíčů, adres serverů a tajemství přímo v kódu. Dynamická je aplikace za běhu na zařízení, kde sledujeme, co dělá s daty a se sítí. Řídíme se metodikou OWASP MASVS a testovací příručkou MASTG, které pojmenovávají, co se má u mobilní aplikace ověřit.

OWASP přitom nemá jeden seznam na všechno: mobilní aplikace se měří proti MASVS, ne proti webovému seznamu OWASP Top 10. Konkrétně jdeme po lokálním úložišti, tedy co si aplikace ukládá do telefonu a jestli jsou to přihlašovací tokeny, osobní data nebo klíče v čitelné podobě. Dál po komunikaci se serverem: jestli běží po TLS a jestli aplikace ověřuje certifikát serveru (cert pinning, tedy připnutí konkrétního certifikátu, aby se nedal podstrčit cizí). A po autentizaci a správě relací, tedy jak aplikace řeší přihlášení, odhlášení a platnost tokenu.

Poslední vrstva je interakce s telefonem a s prostředím. Sledujeme oprávnění, která si aplikace bere, data, která posílá do logů a do zálohy, a chování na zařízení s odemčeným systémem. Co se u toho liší mezi Androidem a iOS, rozebírá další sekce.

Android je otevřenější a jeho build se snáz rozebere. APK jde dekompilovat blíž ke zdrojovému kódu, takže se u něj víc práce věnuje tomu, co je vidět v kódu: natvrdo zadané klíče, adresy testovacích serverů, skryté funkce. Sledujeme i oprávnění, která aplikace požaduje, a komponenty, které vystavuje ostatním aplikacím v telefonu.

iOS je uzavřenější, zato se u něj víc řeší lokální úložiště a odolnost proti spuštění na zařízení s jailbreakem, tedy s obejitým omezením systému, kde má útočník nad telefonem plnou kontrolu. Díváme se, jestli aplikace takové prostředí pozná a jak se v něm chová, a jestli citlivá data leží v keychainu, nebo někde, odkud je jde přečíst snáz.

Když aplikace vychází pro obě platformy, testujeme je vedle sebe, protože stejný kód se na Androidu a iOS chová jinak, a v reportu je oddělujeme, aby bylo jasné, který nález platí kde.

Mobilní aplikace skoro nikdy nestojí sama, mluví s API na serveru, a část chyb je právě tam. Testujeme backend z pohledu mobilního klienta: jestli server věří tomu, co mu aplikace pošle, jestli si jde říct o cizí data záměnou identifikátoru a jestli kontrola oprávnění běží na serveru, ne jen v aplikaci, kterou má útočník v ruce.

Hranici držíme jasně. Backend testujeme potud, pokud s ním mluví mobilní aplikace. Čistě webové API a aplikaci testujeme zvlášť, protože webový klient a business logika celé aplikace jsou samostatný předmět s vlastním rozsahem. Do jedné zakázky se dá spojit obojí, rozsah se pak sečte.

Rozsah drží počet platforem (Android, iOS, nebo obojí), velikost a složitost aplikace a to, kolik má rolí a funkcí. Aplikace s přihlášením, platbou a chatem dá víc práce než jednoduchý katalog; u mobilu rozhoduje počet obrazovek a napojených služeb, ne velikost instalačního souboru.

Kalendářně jde o čtyři až šest člověkodnů a jeden až dva týdny od zahájení po předání reportu. Rozsah a délka testu mobilní aplikace vychází z počtu platforem a složitosti, přesnou nabídku dostanete po vymezení rozsahu. Jeden retest opravených nálezů je součástí ceny.

Nejdřív build aplikace, tedy APK u Androidu a IPA u iOS, nebo přístup k testovací verzi přes TestFlight či interní distribuci. K tomu testovací účty pro každou roli, kterou aplikace zná, ať se dá testovat i to, co vidí přihlášený uživatel, a krátký popis funkcí, aby tester věděl, k čemu aplikace slouží a co v ní nemá jít udělat.

U aplikace, která má vlastní backend, potřebujeme vědět, na které servery se smí sahat, ať se test netrefí do cizí nebo produkční služby mimo rozsah. Pravidla zapojení a okno testování se domlouvají předem stejně jako u ostatních testů.

Smysl dává u aplikací, které drží něco cenného: přihlášení, platby, zdravotní nebo osobní data, přístup do firemních systémů. Čím citlivější data aplikace zpracovává a čím víc jich leží přímo v telefonu, tím větší je dopad jediné chyby v úložišti nebo v komunikaci.

Načasování je nejlepší před vydáním nové aplikace a po každé větší změně, tedy když přibude platba, přihlašování nebo napojení na nový backend. Test těsně před spuštěním zachytí chyby, dokud se dají opravit levně, ne až po incidentu na produkci. Co na mobilních aplikacích při testech nacházíme, rozebírá článek o nejčastějších chybách mobilních aplikací.