Nejčastější chyby v zabezpečení mobilních aplikací

První kategorie chyb je nejsnáz zneužitelná, protože nepotřebuje síť. Aplikace si ukládá do telefonu přihlašovací tokeny, osobní údaje nebo mezipaměť odpovědí ze serveru, a dělá to v čitelné podobě. Kdo se dostane k zařízení nebo k jeho záloze, přečte si to bez jakéhokoli lámání.

Vzniká to zvykem z vývoje na serveru, kde je úložiště za zdí. Na telefonu žádná taková zeď není: na zařízení s odemčeným systémem, tedy s rootem u Androidu nebo s jailbreakem u iOS, i v ladicí záloze jsou soubory aplikace čitelné. Vývojář, který token uloží do prostého souboru nebo do SharedPreferences bez šifrování, počítá s ochranou, kterou mu mobil nedává.

U testu proto hledáme přihlašovací tokeny s dlouhou platností v čitelném souboru, osobní data v lokální databázi bez šifrování a mezipaměť, ve které zůstávají celé odpovědi z API i po odhlášení. Citlivé klíče patří na iOS do keychainu a na Androidu do Keystore, tedy do systémových trezorů chráněných hardwarem, ne do běžného souboru vedle nich.

Druhá kategorie stojí na omylu, že co je uvnitř buildu, nikdo neuvidí. Vývojář vloží do aplikace API klíč, adresu interního serveru nebo přístupové tajemství a spoléhá, že je to schované v binárce. Není. Build aplikace jde stáhnout a rozebrat.

U Androidu se APK dekompiluje blízko ke zdrojovému kódu, u iOS se z IPA dá vytáhnout taky dost. Řetězce jako klíče, tokeny a adresy serverů v nich stojí čitelně nebo za triviálním zakódováním. Schování v kódu není utajení, je to jen o krok víc práce, a ten krok útočník udělá jednou pro všechny uživatele aplikace naráz.

Nejhorší jsou klíče, které otevírají něco na serveru: klíč k platební bráně, k cloudovému úložišti, k API třetí strany. Jakmile je v buildu, je veřejný, a vyměnit ho znamená vydat novou verzi aplikace a počkat, až si ji všichni nainstalují. Tajemství proto patří na server, ne do aplikace, a klient si o data říká přes ověřenou relaci.

Třetí kategorie je o cestě mezi aplikací a serverem. I když komunikace běží po HTTPS, aplikace nemusí kontrolovat, s kým doopravdy mluví, a pak se mezi ni a server dá vložit proxy a provoz číst i měnit. Chybí certificate pinning, tedy připnutí konkrétního certifikátu serveru přímo v aplikaci, aby nevěřila komukoli s platným certifikátem.

Bez pinningu stačí útočníkovi certifikát, kterému telefon věří, a to jde na kontrolovaném zařízení zařídit. Testerská proxy je přesně tenhle scénář: nasadíme vlastní certifikát a čteme, co si aplikace se serverem posílá. Když to jde nám, jde to i útočníkovi na podvržené Wi-Fi nebo na kompromitovaném zařízení.

Narážíme i na tvrdší varianty: přenos, který na části cesty spadne z HTTPS na prosté HTTP, důvěru k jakémukoli certifikátu kvůli usnadnění během vývoje, která zůstala v produkční verzi, a citlivá data poslaná v URL, odkud se dostanou do logů. Transport se testuje celý, ne jen jestli má aplikace u jména zámeček.

Čtvrtá kategorie je nejdražší, protože nejde o telefon, ale o server za ním. Mobilní aplikace je jen klient a útočník ho má celý pod kontrolou: může obejít kontroly v aplikaci a posílat na API cokoli. Když backend věří tomu, co mu klient pošle, je zbytek jen formalita.

Jeden vzor se opakuje: autorizace se řeší v aplikaci, ne na serveru. Tlačítko se schová, obrazovka se nezobrazí, a server předpokládá, že klient hraje fér. Jenže požadavek na API jde poslat i mimo aplikaci. Když server neověří, že přihlášený uživatel smí právě tenhle záznam, dá se záměnou identifikátoru v požadavku číst cizí data. Je to stejná třída chyby jako u webu a testuje se na serveru, ne v telefonu.

Backend proto testujeme z pohledu mobilního klienta: jestli kontrola oprávnění běží na serveru, jestli jdou volání API přehrát a upravit a jestli server ověřuje vstupy. Čistě test webové aplikace a jejího API je samostatná služba, mobilní test se serveru dotýká jen potud, pokud s ním aplikace mluví.

Obrana se váže na ty čtyři kategorie, ne na obecné rady. Citlivá data patří do systémového trezoru, tedy do keychainu nebo Keystore, a do zálohy se nemají dostat vůbec. Tajemství, která otevírají něco na serveru, do buildu nepatří a klient si o data říká přes ověřenou relaci. Transport se zabezpečí certificate pinningem a odstraněním všech úlev, které v kódu zbyly z vývoje. A o autorizaci se rozhoduje na serveru u každého požadavku, protože klientovi nejde věřit.

Aby na nic nezapomněl vývojář ani tester, existuje OWASP MASVS, tedy standard pro bezpečnost mobilních aplikací, který pojmenovává požadavky na úložiště, kryptografii, síť a autentizaci. Dá se použít jako checklist už při vývoji, ne až u testu. Pro web plní stejnou roli ASVS a MASVS je jeho protějšek pro mobil.

Vývojářský checklist ale nenahradí pohled zvenčí. Část těchhle chyb je vidět až na reálném zařízení a v běžící aplikaci, ne v kódu, takže se vyplatí nechat mobilní aplikaci otestovat před vydáním nebo po každé větší změně.

Záleží na tom, jak s nimi aplikace nakládá, ne na značce telefonu. Data ohrožuje nechráněné lokální úložiště, klíče schované přímo v buildu, komunikace bez ověření certifikátu serveru a backend, který věří klientovi. V bezpečí jsou tehdy, když citlivé věci leží v systémovém trezoru, tajemství zůstávají na serveru a o přístup rozhoduje server, ne aplikace v telefonu.

Nestačí. HTTPS zašifruje přenos, ale sám o sobě neřeší, s kým aplikace mluví, ani co se děje na serveru. Bez certificate pinningu se dá mezi aplikaci a server vložit proxy a provoz číst. A i dokonalý transport je k ničemu, když backend nekontroluje oprávnění a věří tomu, co mu klient pošle. HTTPS je základ, ne celá obrana.

Částečně. Cíl je stejný, techniky se liší podle platformy. U Androidu se víc těží z dekompilace APK a z oprávnění a komponent, které aplikace vystavuje ostatním aplikacím v telefonu. U iOS jde spíš o lokální úložiště, keychain a chování na zařízení s jailbreakem. Když aplikace vychází pro obě platformy, testujeme každou zvlášť, protože stejný kód se na nich chová jinak.