Beveiliging in mobiele ontwikkeling: wat het is, welke bedreigingen er zijn en hoe je je verdedigt

Belangrijkste Bedreigingen: OWASP Mobile Top 10

Wat is OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) is een non-profitorganisatie die een ranglijst publiceert van de gevaarlijkste kwetsbaarheden op het gebied van mobiele beveiliging. OWASP Mobile Top 10 is een lijst die ontwikkelaars helpt begrijpen waar ze zich eerst op moeten concentreren. In de versie van 2024 staan problemen met betrekking tot onveilige opslag, zwakke authenticatie en onveilige netwerkcommunicatie bovenaan de ranglijst.

M1: Onveilige Gegevensopslag — het meest voorkomende probleem: wachtwoorden, tokens en persoonlijke gegevens blijven in SharedPreferences, NSUserDefaults of lokale bestanden zonder encryptie. M2: Zwakke Authenticatie — gebrek aan server-side verificatie, zwakke wachtwoorden. M3: Onveilige Netwerkcommunicatie — gebrek aan HTTPS of onjuiste SSL-certificaatverificatie. M4 en M5 hebben betrekking op cryptografie en onjuist API-gebruik.

M6: Onveilige Autorisatie — een gebruiker kan gegevens van een andere gebruiker openen door een ID in een verzoek te vervangen. M7: Code-injectie (SQL Injection, XSS). M8: App-manipulatie — repackaging, code-vervanging. M9 en M10 — gegevenslekken via bibliotheken van derden en reverse engineering. Voor elk van deze bedreigingen bestaan bewezen tegenmaatregelen, en bij IT Sectr passen we ze sinds 2017 toe in alle projecten.

Man-in-the-Middle (MITM)-aanvallen

MITM-aanval vindt plaats wanneer een aanvaller het verkeer tussen de applicatie en de server onderschept. Dit is mogelijk via DNS-spoofing, ARP-spoofing of verbinding met een onbeveiligd Wi-Fi-netwerk. SSL/TLS-certificaten en Certificate Pinning worden gebruikt voor bescherming.

Certificate Pinning is een mechanisme waarbij de applicatie verifieert dat het servercertificaat overeenkomt met een vooraf opgeslagen certificaat in de applicatiecode. Zelfs als een aanvaller het certificaat vervangt via een proxy (bijvoorbeeld Burp Suite), zal de applicatie de verbinding weigeren. Pinning bestaat in twee vormen: Public Key Pinning en Certificate Hash Pinning.

Encryptie en Hashing: AES, RSA, SSL/TLS

Symmetrische Encryptie: AES

AES (Advanced Encryption Standard) is een symmetrisch encryptie-algoritme, de basis van gegevensbeveiliging op het apparaat. AES gebruikt dezelfde sleutel voor het versleutelen en ontsleutelen van gegevens. AES ondersteunt sleutels van 128, 192 of 256 bits. In mobiele ontwikkeling wordt AES-256 gebruikt voor het versleutelen van gegevens op het apparaat: bestanden, cache, records in de lokale database.

AES-modi: GCM (aanbevolen) — biedt gegevensauthenticatie, CBC — basismodus met blokketening, ECB — onveilig, niet gebruiken. Voor iOS is AES beschikbaar via CommonCrypto (CCOptions), voor Android — via Cipher in Java Cryptography Architecture (JCA). Belangrijk: de versleutelingssleutel mag nooit in de applicatiecode worden opgeslagen — gebruik Keychain/Keystore.

Asymmetrische Encryptie: RSA — gebruikt een sleutelpaar (openbaar en privé). RSA wordt gebruikt voor het versleutelen van kleine hoeveelheden gegevens — meestal voor het uitwisselen van een symmetrische sleutel tussen client en server. De minimale RSA-sleutellengte is 2048 bits (4096 aanbevolen). Op iOS is RSA beschikbaar via Security Framework (SecKeyCreateRandomKey), op Android — via KeyPairGenerator in Android Keystore.

Hashing en SSL/TLS

Hashing (SHA-256, SHA-3) is een onomkeerbare transformatie van gegevens naar een string met vaste lengte. Hashes worden gebruikt voor het verifiëren van gegevensintegriteit en het opslaan van wachtwoorden. Gebruik voor wachtwoorden altijd bcrypt, scrypt of Argon2 — gewone SHA-256 is kwetsbaar voor rainbow table-aanvallen. SSL/TLS is een protocol voor het versleutelen van netwerkverkeer tussen client en server. De moderne standaard is TLS 1.3, dat Perfect Forward Secrecy (PFS) biedt.

TLS 1.3 is sneller dan zijn voorgangers: de handshake duurt één round trip in plaats van twee. Op Android wordt de minimale TLS-versie geconfigureerd via SSLSocket, op iOS — via ATS (App Transport Security), dat standaard TLS 1.2 of hoger vereist. ATS kan alleen voor specifieke domeinen met rechtvaardiging worden uitgeschakeld.

Veilige Opslag: Keychain en Keystore

iOS: Keychain

Keychain (Sleutelhanger) is een beveiligde opslag in iOS / macOS voor wachtwoorden, versleutelingssleutels, certificaten en tokens. Gegevens in Keychain worden versleuteld met een hardwaresleutel die uniek is voor elk apparaat. Toegang tot Keychain wordt gecontroleerd via Security Framework (SecItemAdd, SecItemCopyMatching). Keychain wordt automatisch vergrendeld wanneer het apparaat wordt vergrendeld en wordt versleuteld met behulp van Secure Enclave.

Android: Keystore

Android Keystore is een systeemopslag voor cryptografische sleutels, geïsoleerd van de applicatie. Vanaf Android 6.0 (API 23) gebruikt Keystore hardware-ondersteuning (TEE — Trusted Execution Environment) op apparaten met een beveiligingschip. Sleutels in Keystore verlaten nooit het beveiligde gebied — de applicatie ontvangt alleen een handle voor versleutelings- en ondertekeningsbewerkingen.

SharedPreferences en NSUserDefaults zijn niet ontworpen voor het opslaan van gevoelige gegevens — ze slaan informatie op in platte tekst. Gebruik voor gegevensbescherming EncryptedSharedPreferences (Android) of versleutel gegevens voordat je ze opslaat in UserDefaults (iOS). Bij IT Sectr gebruiken we altijd Keychain en Keystore voor toegangstokens en wachtwoorden.

Authenticatie: OAuth 2.0, JWT en Biometrie

OAuth 2.0 en OpenID Connect

OAuth 2.0 is een gedelegeerd autorisatieprotocol dat veilige toegang biedt tot gebruikersbronnen zonder het wachtwoord te verzenden. In mobiele applicaties wordt meestal de Authorization Code Flow met PKCE (Proof Key for Code Exchange) gebruikt. PKCE voorkomt onderschepping van de autorisatiecode — een verplichte vereiste voor mobiele applicaties.

OpenID Connect (OIDC) is een uitbreiding bovenop OAuth 2.0 voor gebruikersauthenticatie. OIDC voegt een ID Token in JWT-formaat toe dat gebruikersinformatie bevat (naam, e-mail, id). De OAuth 2.0 + OIDC-stroom omvat: doorverwijzen van de gebruiker naar de inlogpagina, verkrijgen van een autorisatiecode, uitwisselen van de code voor tokens (access + refresh + id), gebruiken van de access token voor API-verzoeken.

JWT: Access, Refresh en Session Tokens

JWT (JSON Web Token) is een compact, URL-veilig tokenformaat dat claims in JSON-formaat bevat. JWT bestaat uit drie delen: header (type en handtekeningalgoritme), payload (gegevens) en handtekening. Access Token is een kortlevende token (15–60 minuten) voor API-toegang. Refresh Token is een langlevende token (dagen/weken) voor het verkrijgen van een nieuwe access token zonder opnieuw in te loggen.

Session Token is een traditionele benadering waarbij de server de sessie opslaat in een database of Redis, en de client een willekeurige identificatie ontvangt. In mobiele ontwikkeling heeft JWT de voorkeur: het vereist geen server-side sessieopslag, bevat alle informatie in zichzelf en is eenvoudig te verifiëren. JWT kan echter niet onmiddellijk worden ingetrokken — dit is een afweging die wordt opgelost door een korte levensduur van de access token en het gebruik van refresh tokens.

Biometrische Authenticatie

Face ID en Touch ID op iOS, Vingerafdrukauthenticatie op Android — biometrische authenticatiemethoden die unieke fysieke kenmerken van de gebruiker gebruiken. Op iOS werkt biometrie via LocalAuthentication (LAContext), op Android — via BiometricPrompt (Android 9+) of FingerprintManager (verouderd). Biometrie wordt gebruikt voor het ontgrendelen van de app, het bevestigen van betalingen en toegang tot beschermde gegevens.

Belangrijke nuances: biometrie is een handige UX, maar geen vervanging voor serverauthenticatie. Na succesvolle biometrische verificatie moet de applicatie een access token van de server verkrijgen. Controleer op Android altijd of het apparaat Class 3 (Strong) biometrie gebruikt, niet alleen camera-gebaseerde gezichtsherkenning (Class 1).

Codebescherming: ProGuard, R8 en Root Detection

Obfuscatie: ProGuard en R8

ProGuard is een tool voor obfuscatie, compressie en optimalisatie van Java-bytecode voor Android, die de codebeveiliging tegen reverse engineering verbetert. R8 is de opvolger, geïntegreerd in Gradle sinds Android Studio 3.4. R8 voert vier taken uit: compressie (verwijdert ongebruikte klassen en methoden), optimalisatie (inlinet methoden, vereenvoudigt code), obfuscatie (hernoemt klassen en methoden naar korte namen) en pre-verificatie (bytecode-controle).

DexGuard is een commerciële versie van ProGuard met uitgebreide beveiliging: tekenreeksversleuteling, resource-obfuscatie, bescherming tegen repackaging, APK-integriteitscontrole. Voor de meeste projecten is R8 voldoende, maar voor financiële en bankapplicaties biedt DexGuard een extra beveiligingslaag. R8 wordt ingeschakeld via build.gradle: minifyEnabled = true en proguardFiles.

Root en Jailbreak Detection

Root Detection (Android) en Jailbreak Detection (iOS) zijn mechanismen die controleren of er superuser-rechten op het apparaat zijn verkregen. Op gecompromitteerde apparaten is het mogelijk om procesgeheugen te lezen, verkeer te onderscheppen en code te vervangen. Voor controle op Android wordt de aanwezigheid van het SU-binary-bestand, testhandtekening-sleutels en niet-standaard build-vlaggen gebruikt.

RASP (Runtime Application Self-Protection) is een technologie die de applicatie beschermt tijdens de uitvoering. RASP detecteert pogingen tot debuggen, repackaging, code-injectie en beëindigt de applicatie wanneer bedreigingen worden gedetecteerd. Voorbeelden van RASP-oplossingen: Dexter, Guardsquare, Promon. RASP werkt tijdens runtime en reageert op afwijkingen — in tegenstelling tot statische obfuscatie, die code beschermt vóór uitvoering.

Reverse Engineering is het proces van het terugwinnen van broncode uit een gecompileerde applicatie. Tools: JADX (APK-decompiler), Ghidra, IDA Pro, Hopper. Bescherming tegen Reverse Engineering is een combinatie van obfuscatie, tekenreeksversleuteling, integriteitscontrole en Root Detection. Volledige bescherming bestaat niet — het doel is om reverse engineering duur genoeg te maken voor de aanvaller.