Biztonság a mobilfejlesztésben: mi ez, milyen fenyegetések vannak és hogyan védekezzünk

Fő Fenyegetések: OWASP Mobile Top 10

Mi az OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) egy nonprofit szervezet, amely a legveszélyesebb mobilitásbiztonsági sebezhetőségek rangsorát teszi közzé. Az OWASP Mobile Top 10 egy lista, amely segít a fejlesztőknek megérteni, mire kell először összpontosítaniuk. A 2024-es verzióban a nem biztonságos tárolással, gyenge hitelesítéssel és nem biztonságos hálózati kommunikációval kapcsolatos problémák vezetik a rangsort.

M1: Nem biztonságos adattárolás — a leggyakoribb probléma: a jelszavak, tokenek és személyes adatok titkosítás nélkül maradnak a SharedPreferences, NSUserDefaults vagy helyi fájlokban. M2: Gyenge hitelesítés — hiányzó szerveroldali ellenőrzés, gyenge jelszavak. M3: Nem biztonságos hálózati kommunikáció — HTTPS hiánya vagy helytelen SSL-tanúsítvány-ellenőrzés. M4 és M5 a kriptográfiához és a helytelen API-használathoz kapcsolódik.

M6: Nem biztonságos engedélyezés — a felhasználó hozzáférhet egy másik felhasználó adataihoz egy azonosító kérésben történő helyettesítésével. M7: Kódbefecskendezés (SQL Injection, XSS). M8: Alkalmazás manipuláció — újracsomagolás, kódhelyettesítés. M9 és M10 — adatszivárgás harmadik féltől származó könyvtáraken keresztül és visszafejtés. Mindegyik fenyegetésre léteznek bevált ellenintézkedések, és az IT Sectr-nél 2017 óta alkalmazzuk ezeket minden projektben.

Man-in-the-Middle (MITM) támadások

MITM-támadás akkor történik, amikor egy támadó elfogja az alkalmazás és a szerver közötti forgalmat. Ez lehetséges DNS-spoofing, ARP-spoofing vagy nem biztonságos Wi-Fi hálózathoz való csatlakozás útján. Védelemre SSL/TLS-tanúsítványok és Certificate Pinning használatos.

Certificate Pinning egy olyan mechanizmus, amelyben az alkalmazás ellenőrzi, hogy a szerver tanúsítványa megegyezik-e az alkalmazáskódban előre tárolttal. Még ha a támadó ki is cseréli a tanúsítványt egy proxyn keresztül (pl. Burp Suite), az alkalmazás elutasítja a kapcsolatot. A Pinning két típusú: Public Key Pinning és Certificate Hash Pinning.

Titkosítás és Hash-elés: AES, RSA, SSL/TLS

Szimmetrikus titkosítás: AES

AES (Advanced Encryption Standard) egy szimmetrikus titkosítási algoritmus, az eszközön lévő adatbiztonság alapja. Az AES ugyanazt a kulcsot használja az adatok titkosításához és visszafejtéséhez. Az AES 128, 192 vagy 256 bites kulcsokat támogat. A mobilfejlesztésben az AES-256-ot használják az eszközön lévő adatok (fájlok, gyorsítótár, helyi adatbázis rekordok) titkosításához.

AES módok: GCM (ajánlott) — adathitelesítést biztosít, CBC — alapmód blokkláncolással, ECB — nem biztonságos, ne használja. iOS esetén az AES a CommonCrypton (CCOptions) keresztül érhető el, Android esetén — a Java Cryptography Architecture (JCA) Cipher osztályán keresztül. Fontos: a titkosítási kulcsot soha nem szabad az alkalmazáskódban tárolni — használja a Keychain/Keystore-t.

Aszimmetrikus titkosítás: RSA — kulcspárt (nyilvános és privát) használ. Az RSA kis mennyiségű adat titkosítására szolgál — jellemzően szimmetrikus kulcs cseréjére a kliens és a szerver között. A minimális RSA-kulcshossz 2048 bit (4096 ajánlott). iOS-en az RSA a Security Frameworkön (SecKeyCreateRandomKey) keresztül érhető el, Androidon — az Android Keystore KeyPairGenerator-jén keresztül.

Hash-elés és SSL/TLS

Hash-elés (SHA-256, SHA-3) az adatok visszafordíthatatlan átalakítása rögzített hosszúságú karakterlánccá. A hash-eket adatintegritás ellenőrzésére és jelszavak tárolására használják. Jelszavakhoz feltétlenül használjon bcrypt, scrypt vagy Argon2-t — a sima SHA-256 sebezhető a szivárványtábla-támadásokkal szemben. SSL/TLS egy protokoll a kliens és a szerver közötti hálózati forgalom titkosítására. A modern szabvány a TLS 1.3, amely Perfect Forward Secrecy-t (PFS) biztosít.

TLS 1.3 gyorsabb elődeinél: a kézfogás egy helyett egyetlen oda-vissza utat vesz igénybe. Androidon a minimális TLS-verziót az SSLSocketen keresztül állítják be, iOS-en — az ATS-en (App Transport Security) keresztül, amely alapértelmezés szerint TLS 1.2-t vagy magasabbat igényel. Az ATS csak meghatározott tartományokra tiltható le indoklással.

Biztonságos Tárolás: Keychain és Keystore

iOS: Keychain

Keychain (Kulcskarika) egy biztonságos tároló iOS / macOS rendszerben jelszavak, titkosítási kulcsok, tanúsítványok és tokenek számára. A Keychainben lévő adatok egy hardveres kulccsal vannak titkosítva, amely minden eszközön egyedi. A Keychainhez való hozzáférést a Security Framework (SecItemAdd, SecItemCopyMatching) szabályozza. A Keychain automatikusan zárolódik az eszköz zárolásakor, és a Secure Enclave segítségével van titkosítva.

Android: Keystore

Android Keystore egy rendszertároló kriptográfiai kulcsok számára, elkülönítve az alkalmazástól. Az Android 6.0-tól (API 23) kezdve a Keystore hardvertámogatást (TEE — Trusted Execution Environment) használ a biztonsági chippel rendelkező eszközökön. A Keystore-ban lévő kulcsok soha nem hagyják el a védett területet — az alkalmazás csak egy fogantyút (handle) kap a titkosítási és aláírási műveletekhez.

SharedPreferences és NSUserDefaults nem érzékeny adatok tárolására lettek tervezve — nyílt szöveg formátumban tárolják az információkat. Adatvédelemhez használja az EncryptedSharedPreferences-t (Android) vagy titkosítsa az adatokat, mielőtt elmenti a UserDefaults-ba (iOS). Az IT Sectr-nél mindig a Keychain-t és a Keystore-t használjuk hozzáférési tokenekhez és jelszavakhoz.

Hitelesítés: OAuth 2.0, JWT és Biometria

OAuth 2.0 és OpenID Connect

OAuth 2.0 egy delegált engedélyezési protokoll, amely biztonságos hozzáférést biztosít a felhasználó erőforrásaihoz a jelszó továbbítása nélkül. Mobilalkalmazásokban leggyakrabban az Authorization Code Flow-t használják PKCE-vel (Proof Key for Code Exchange). A PKCE megakadályozza az engedélyezési kód elfogását — ez kötelező követelmény a mobilalkalmazások számára.

OpenID Connect (OIDC) egy kiterjesztés az OAuth 2.0 tetején a felhasználói hitelesítéshez. Az OIDC hozzáad egy ID Token-t JWT formátumban, amely a felhasználó adatait tartalmazza (név, e-mail, azonosító). Az OAuth 2.0 + OIDC folyamat a következőket foglalja magában: a felhasználó átirányítása a bejelentkezési oldalra, engedélyezési kód beszerzése, a kód cseréje tokenekre (access + refresh + id), a hozzáférési token használata API-kérésekhez.

JWT: Hozzáférési, Frissítési és Munkamenet Tokenek

JWT (JSON Web Token) egy kompakt, URL-biztos token formátum, amely JSON formátumú követeléseket (claims) tartalmaz. A JWT három részből áll: fejléc (típus és aláírási algoritmus), hasznos adat (payload) és aláírás. A hozzáférési token egy rövid élettartamú token (15-60 perc) API-hozzáféréshez. A frissítési token egy hosszú élettartamú token (napok/hetek) új hozzáférési token beszerzéséhez anélkül, hogy újra be kellene jelentkezni.

Munkamenet token egy hagyományos megközelítés, ahol a szerver a munkamenetet egy adatbázisban vagy Redis-ben tárolja, a kliens pedig egy véletlenszerű azonosítót kap. A mobilfejlesztésben a JWT előnyösebb: nem igényel szerveroldali munkamenet-tárolást, minden információt magában foglal, és könnyen ellenőrizhető. A JWT azonban nem vonható vissza azonnal — ez egy kompromisszum, amelyet a rövid hozzáférési token élettartam és a frissítési tokenek használata old meg.

Biometrikus Hitelesítés

Face ID és Touch ID iOS-en, Ujjlenyomat-hitelesítés Androidon — biometrikus hitelesítési módszerek, amelyek a felhasználó egyedi fizikai jellemzőit használják. iOS-en a biometria a LocalAuthentication (LAContext) segítségével működik, Androidon — a BiometricPrompt (Android 9+) vagy FingerprintManager (elavult) segítségével. A biometriát az alkalmazás zárolásának feloldására, fizetések megerősítésére és védett adatokhoz való hozzáférésre használják.

Fontos árnyalatok: a biometria kényelmes felhasználói élmény, de nem helyettesíti a szerveroldali hitelesítést. Sikeres biometrikus ellenőrzés után az alkalmazásnak hozzáférési tokent kell beszereznie a szervertől. Androidon ellenőrizze, hogy az eszköz 3. osztályú (Erős) biometriát használ-e, nem csak kamerán alapuló arcfelismerést (1. osztály).

Kódvédelem: ProGuard, R8 és Root Detection

Obfuszkáció: ProGuard és R8

ProGuard egy obfuszkációs, tömörítési és optimalizálási eszköz Java bájtkódhoz Androidon, amely növeli a kód biztonságát a visszafejtéssel szemben. Az R8 az utódja, amely az Android Studio 3.4 óta be van építve a Gradle-be. Az R8 négy feladatot lát el: tömörítés (eltávolítja a nem használt osztályokat és metódusokat), optimalizálás (metódusok beillesztése, kód egyszerűsítése), obfuszkáció (osztályok és metódusok átnevezése rövid nevekre) és előellenőrzés (bájtkód ellenőrzése).

DexGuard a ProGuard kereskedelmi verziója kibővített védelemmel: karakterlánc-titkosítás, erőforrás-obfuszkáció, védelem az újracsomagolás ellen, APK-integritás ellenőrzése. A legtöbb projekthez az R8 elegendő, de pénzügyi és banki alkalmazásokhoz a DexGuard további biztonsági réteget nyújt. Az R8 a build.gradle-en keresztül aktiválható: minifyEnabled = true és proguardFiles.

Root és Jailbreak észlelés

Root Detection (Android) és Jailbreak Detection (iOS) olyan mechanizmusok, amelyek ellenőrzik, hogy az eszközön szuperfelhasználói jogosultságokat szereztek-e. Sérült eszközökön lehetséges a folyamatmemória olvasása, a forgalom elfogása és a kód helyettesítése. Androidon az ellenőrzéshez az SU bináris fájl jelenlétét, teszt aláírási kulcsokat és nem szabványos build-flag-eket használnak.

RASP (Runtime Application Self-Protection) egy technológia, amely védi az alkalmazást a végrehajtás során. A RASP észleli a hibakeresési, újracsomagolási, kódbefecskendezési kísérleteket, és fenyegetések észlelésekor leállítja az alkalmazást. Példák RASP-megoldásokra: Dexter, Guardsquare, Promon. A RASP futásidőben működik és reagál az anomáliákra — ellentétben a statikus obfuszkációval, amely a kódot a végrehajtás előtt védi.

Visszafejtés a forráskód helyreállításának folyamata egy lefordított alkalmazásból. Eszközök: JADX (APK-visszafejtő), Ghidra, IDA Pro, Hopper. A visszafejtés elleni védelem az obfuszkáció, a karakterlánc-titkosítás, az integritás-ellenőrzés és a Root Detection kombinációja. Teljes védelem nem létezik — a cél az, hogy a visszafejtést elég költségessé tegyük a támadó számára.