Säkerhet i mobil utveckling: vad det är, vilka hot som finns och hur man försvarar sig

Viktigaste Hoten: OWASP Mobile Top 10

Vad är OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) är en ideell organisation som publicerar en ranking av de farligaste sårbarheterna inom mobilsäkerhet. OWASP Mobile Top 10 är en lista som hjälper utvecklare att förstå vad de ska fokusera på först. I versionen från 2024 toppas listan av problem relaterade till osäker lagring, svag autentisering och osäker nätverkskommunikation.

M1: Osäker Datalagring — det vanligaste problemet: lösenord, tokens och personuppgifter ligger kvar i SharedPreferences, NSUserDefaults eller lokala filer utan kryptering. M2: Svag Autentisering — brist på server-side verifiering, svaga lösenord. M3: Osäker Nätverkskommunikation — brist på HTTPS eller felaktig SSL-certifikatsverifiering. M4 och M5 är relaterade till kryptografi och felaktig API-användning.

M6: Osäker Auktorisering — en användare kan komma åt en annan användares data genom att byta ut ett ID i en begäran. M7: Kod-injektion (SQL Injection, XSS). M8: App-manipulation — återpaketering, kodbyte. M9 och M10 — dataläckage via tredjepartsbibliotek och reverse engineering. För vart och ett av dessa hot finns beprövade motåtgärder, och på IT Sectr har vi tillämpat dem i alla projekt sedan 2017.

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

MITM-attack inträffar när en angripare fångar upp trafiken mellan applikationen och servern. Detta är möjligt genom DNS-spoofing, ARP-spoofing eller anslutning till ett oskyddat Wi-Fi-nätverk. SSL/TLS-certifikat och Certificate Pinning används för skydd.

Certificate Pinning är en mekanism där applikationen verifierar att serverns certifikat matchar ett förlagrat certifikat i applikationskoden. Även om en angripare byter ut certifikatet via en proxy (t.ex. Burp Suite), kommer applikationen att avvisa anslutningen. Pinning finns i två typer: Public Key Pinning och Certificate Hash Pinning.

Kryptering och Hashning: AES, RSA, SSL/TLS

Symmetrisk Kryptering: AES

AES (Advanced Encryption Standard) är en symmetrisk krypteringsalgoritm, grunden för datasäkerhet på enheten. AES använder samma nyckel för att kryptera och dekryptera data. AES stöder nycklar på 128, 192 eller 256 bitar. Inom mobil utveckling används AES-256 för att kryptera data på enheten: filer, cache, poster i den lokala databasen.

AES-lägen: GCM (rekommenderas) — ger dataautentisering, CBC — grundläge med blockkedjning, ECB — osäkert, använd inte. För iOS är AES tillgängligt via CommonCrypto (CCOptions), för Android — via Cipher i Java Cryptography Architecture (JCA). Viktigt: krypteringsnyckeln får aldrig lagras i applikationskoden — använd Keychain/Keystore.

Asymmetrisk Kryptering: RSA — använder ett nyckelpar (offentlig och privat). RSA används för att kryptera små mängder data — vanligtvis för att utbyta en symmetrisk nyckel mellan klient och server. Den minsta RSA-nyckellängden är 2048 bitar (4096 rekommenderas). På iOS är RSA tillgängligt via Security Framework (SecKeyCreateRandomKey), på Android — via KeyPairGenerator i Android Keystore.

Hashning och SSL/TLS

Hashning (SHA-256, SHA-3) är en irreversibel omvandling av data till en sträng med fast längd. Hashar används för att verifiera dataintegritet och lagra lösenord. För lösenord måste du använda bcrypt, scrypt eller Argon2 — vanlig SHA-256 är sårbar för rainbow table-attacker. SSL/TLS är ett protokoll för att kryptera nätverkstrafik mellan klient och server. Den moderna standarden är TLS 1.3, som ger Perfect Forward Secrecy (PFS).

TLS 1.3 är snabbare än sina föregångare: handskakningen tar en rundtur istället för två. På Android konfigureras den lägsta TLS-versionen via SSLSocket, på iOS — via ATS (App Transport Security), som som standard kräver TLS 1.2 eller högre. ATS kan endast inaktiveras för specifika domäner med motivering.

Säker Lagring: Keychain och Keystore

iOS: Keychain

Keychain (Nyckelring) är en säker lagring i iOS / macOS för lösenord, krypteringsnycklar, certifikat och tokens. Data i Keychain krypteras med en hårdvarunyckel som är unik för varje enhet. Åtkomst till Keychain kontrolleras via Security Framework (SecItemAdd, SecItemCopyMatching). Keychain låses automatiskt när enheten låses och krypteras med Secure Enclave.

Android: Keystore

Android Keystore är en systemlagring för kryptografiska nycklar, isolerad från applikationen. Från och med Android 6.0 (API 23) använder Keystore hårdvarustöd (TEE — Trusted Execution Environment) på enheter med ett säkerhetschip. Nycklar i Keystore lämnar aldrig det skyddade området — applikationen får endast ett handtag för krypterings- och signeringsoperationer.

SharedPreferences och NSUserDefaults är inte avsedda för lagring av känslig data — de lagrar information i klartext. För dataskydd, använd EncryptedSharedPreferences (Android) eller kryptera data innan du sparar i UserDefaults (iOS). På IT Sectr använder vi alltid Keychain och Keystore för åtkomsttokens och lösenord.

Autentisering: OAuth 2.0, JWT och Biometri

OAuth 2.0 och OpenID Connect

OAuth 2.0 är ett delegerat auktoriseringsprotokoll som ger säker åtkomst till användarens resurser utan att skicka lösenordet. I mobila applikationer används oftast Authorization Code Flow med PKCE (Proof Key for Code Exchange). PKCE förhindrar avlyssning av auktoriseringskoden — ett obligatoriskt krav för mobila applikationer.

OpenID Connect (OIDC) är en utökning ovanpå OAuth 2.0 för användarautentisering. OIDC lägger till en ID-token i JWT-format som innehåller användarinformation (namn, e-post, id). OAuth 2.0 + OIDC-flödet inkluderar: omdirigering av användaren till inloggningssidan, erhållande av en auktoriseringskod, utbyte av koden mot tokens (access + refresh + id), användning av åtkomsttoken för API-förfrågningar.

JWT: Åtkomst-, Uppdaterings- och Sessions-tokens

JWT (JSON Web Token) är ett kompakt, URL-säkert tokenformat som innehåller claims i JSON-format. JWT består av tre delar: header (typ och signeringsalgoritm), payload (data) och signatur. Åtkomsttoken är en kortlivad token (15–60 minuter) för API-åtkomst. Uppdateringstoken är en långlivad token (dagar/veckor) för att få en ny åtkomsttoken utan att logga in igen.

Sessionstoken är ett traditionellt tillvägagångssätt där servern lagrar sessionen i en databas eller Redis, och klienten får en slumpmässig identifierare. Inom mobil utveckling föredras JWT: det kräver ingen server-side sessionslagring, innehåller all information inom sig själv och är lätt att verifiera. JWT kan dock inte återkallas omedelbart — detta är en avvägning som löses med en kort livslängd för åtkomsttoken och användning av uppdateringstokens.

Biometrisk Autentisering

Face ID och Touch ID på iOS, Fingeravtrycksautentisering på Android — biometriska autentiseringsmetoder som använder unika fysiska egenskaper hos användaren. På iOS fungerar biometri via LocalAuthentication (LAContext), på Android — via BiometricPrompt (Android 9+) eller FingerprintManager (föråldrad). Biometri används för att låsa upp appen, bekräfta betalningar och komma åt skyddade data.

Viktiga nyanser: biometri är en bekväm användarupplevelse, men inte en ersättning för serverautentisering. Efter framgångsrik biometrisk verifiering bör applikationen hämta en åtkomsttoken från servern. På Android måste du kontrollera att enheten använder Klass 3 (Stark) biometri, inte bara kamera-baserad ansiktsigenkänning (Klass 1).

Kodskydd: ProGuard, R8 och Root Detection

Obfuskering: ProGuard och R8

ProGuard är ett verktyg för obfuskering, komprimering och optimering av Java-bytekod för Android, vilket ökar kodens säkerhet mot reverse engineering. R8 är dess efterföljare, inbyggd i Gradle sedan Android Studio 3.4. R8 utför fyra uppgifter: komprimering (tar bort oanvända klasser och metoder), optimering (inline-metoder, förenklar kod), obfuskering (byter namn på klasser och metoder till korta namn) och förverifiering (bytekodskontroll).

DexGuard är en kommersiell version av ProGuard med utökat skydd: strängkryptering, resurs-obfuskering, skydd mot återpaketering, APK-integritetskontroll. För de flesta projekt räcker R8, men för finansiella och bankapplikationer ger DexGuard ett extra säkerhetslager. R8 aktiveras via build.gradle: minifyEnabled = true och proguardFiles.

Root- och Jailbreak-detektering

Root Detection (Android) och Jailbreak Detection (iOS) är mekanismer som kontrollerar om superanvändarbehörigheter har erhållits på enheten. På komprometterade enheter är det möjligt att läsa processminne, avlyssna trafik och byta ut kod. För kontroll på Android används förekomsten av den SU-binära filen, testsignaturnycklar och icke-standardiserade byggflaggor.

RASP (Runtime Application Self-Protection) är en teknik som skyddar applikationen under körning. RASP upptäcker försök till felsökning, återpaketering, kod-injektion och avslutar applikationen när hot upptäcks. Exempel på RASP-lösningar: Dexter, Guardsquare, Promon. RASP fungerar vid körning och reagerar på avvikelser — till skillnad från statisk obfuskering, som skyddar kod före körning.

Reverse Engineering är processen att återställa källkod från en kompilerad applikation. Verktyg: JADX (APK-dekompilator), Ghidra, IDA Pro, Hopper. Skydd mot Reverse Engineering är en kombination av obfuskering, strängkryptering, integritetskontroll och Root Detection. Fullständigt skydd finns inte — målet är att göra reverse engineering tillräckligt dyr för angriparen.