Securitatea în dezvoltarea mobilă: ce este, ce amenințări există și cum să te aperi

Amenințări Principale: OWASP Mobile Top 10

Ce este OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) este o organizație non-profit care publică un clasament al celor mai periculoase vulnerabilități de securitate mobilă. OWASP Mobile Top 10 este o listă care îi ajută pe dezvoltatori să înțeleagă pe ce să se concentreze mai întâi. În versiunea 2024, problemele legate de stocarea nesigură, autentificarea slabă și comunicarea nesigură în rețea conduc clasamentul.

M1: Stocarea Nesigură a Datelor — cea mai frecventă problemă: parole, tokenuri și date personale rămân în SharedPreferences, NSUserDefaults sau fișiere locale fără criptare. M2: Autentificare Slabă — lipsa verificării pe partea serverului, parole slabe. M3: Comunicare Nesigură în Rețea — lipsa HTTPS sau verificarea incorectă a certificatului SSL. M4 și M5 sunt legate de criptografie și utilizarea incorectă a API-urilor.

M6: Autorizare Nesigură — un utilizator poate accesa datele altui utilizator prin substituirea unui ID într-o cerere. M7: Injectare de Cod (SQL Injection, XSS). M8: Manipularea Aplicației — repachetare, substituire de cod. M9 și M10 — scurgere de date prin biblioteci terțe și inginerie inversă. Pentru fiecare dintre aceste amenințări există contramăsuri dovedite, iar la IT Sectr le aplicăm în toate proiectele din 2017.

Atacuri Man-in-the-Middle (MITM)

Atacul MITM are loc atunci când un atacator interceptează traficul dintre aplicație și server. Acest lucru este posibil prin falsificare DNS, ARP spoofing sau conectarea la o rețea Wi-Fi nesecurizată. Pentru protecție se folosesc certificate SSL/TLS și Certificate Pinning.

Certificate Pinning este un mecanism prin care aplicația verifică dacă certificatul serverului se potrivește cu unul pre-stocat în codul aplicației. Chiar dacă un atacator substituie certificatul printr-un proxy (de exemplu, Burp Suite), aplicația va respinge conexiunea. Pinning este de două tipuri: Public Key Pinning și Certificate Hash Pinning.

Criptare și Hash: AES, RSA, SSL/TLS

Criptare Simetrică: AES

AES (Advanced Encryption Standard) este un algoritm de criptare simetrică, fundamentul securității datelor pe dispozitiv. AES folosește aceeași cheie pentru criptarea și decriptarea datelor. AES suportă chei de 128, 192 sau 256 de biți. În dezvoltarea mobilă, AES-256 este utilizat pentru criptarea datelor pe dispozitiv: fișiere, cache, înregistrări în baza de date locală.

Moduri AES: GCM (recomandat) — asigură autentificarea datelor, CBC — mod de bază cu lanț de blocuri, ECB — nesigur, nu îl utilizați. Pentru iOS, AES este disponibil prin CommonCrypto (CCOptions), pentru Android — prin Cipher în Java Cryptography Architecture (JCA). Important: cheia de criptare nu trebuie niciodată stocată în codul aplicației — utilizați Keychain/Keystore.

Criptare Asimetrică: RSA — folosește o pereche de chei (publică și privată). RSA este utilizat pentru criptarea unor cantități mici de date — de obicei pentru schimbul unei chei simetrice între client și server. Lungimea minimă a cheii RSA este de 2048 de biți (4096 recomandat). Pe iOS, RSA este disponibil prin Security Framework (SecKeyCreateRandomKey), pe Android — prin KeyPairGenerator în Android Keystore.

Hash și SSL/TLS

Hash (SHA-256, SHA-3) este o transformare ireversibilă a datelor într-un șir de lungime fixă. Hashurile sunt utilizate pentru verificarea integrității datelor și stocarea parolelor. Pentru parole, utilizați obligatoriu bcrypt, scrypt sau Argon2 — SHA-256 simplu este vulnerabil la atacuri cu tabele rainbow. SSL/TLS este un protocol pentru criptarea traficului de rețea între client și server. Standardul modern este TLS 1.3, care asigură Perfect Forward Secrecy (PFS).

TLS 1.3 este mai rapid decât predecesorii săi: handshake-ul durează o singură rundă în loc de două. Pe Android, versiunea minimă de TLS se configurează prin SSLSocket, pe iOS — prin ATS (App Transport Security), care implicit necesită TLS 1.2 sau superior. ATS poate fi dezactivat doar pentru domenii specifice cu justificare.

Stocare Sigură: Keychain și Keystore

iOS: Keychain

Keychain (Set de Chei) este un depozit securizat în iOS / macOS pentru parole, chei de criptare, certificate și tokenuri. Datele din Keychain sunt criptate cu o cheie hardware unică pentru fiecare dispozitiv. Accesul la Keychain este controlat prin Security Framework (SecItemAdd, SecItemCopyMatching). Keychain se blochează automat când dispozitivul este blocat și este criptat folosind Secure Enclave.

Android: Keystore

Android Keystore este un depozit de sistem pentru chei criptografice, izolat de aplicație. Începând cu Android 6.0 (API 23), Keystore utilizează suport hardware (TEE — Trusted Execution Environment) pe dispozitivele cu cip de securitate. Cheile din Keystore nu părăsesc niciodată zona securizată — aplicația primește doar un handle pentru operațiile de criptare și semnare.

SharedPreferences și NSUserDefaults nu sunt concepute pentru stocarea datelor sensibile — stochează informații în text simplu. Pentru protecția datelor, utilizați EncryptedSharedPreferences (Android) sau criptați datele înainte de a le salva în UserDefaults (iOS). La IT Sectr, folosim întotdeauna Keychain și Keystore pentru tokenuri de acces și parole.

Autentificare: OAuth 2.0, JWT și Biometrie

OAuth 2.0 și OpenID Connect

OAuth 2.0 este un protocol de autorizare delegată care asigură acces securizat la resursele utilizatorului fără transmiterea parolei. În aplicațiile mobile, cel mai frecvent este utilizat Authorization Code Flow cu PKCE (Proof Key for Code Exchange). PKCE previne interceptarea codului de autorizare — o cerință obligatorie pentru aplicațiile mobile.

OpenID Connect (OIDC) este o extensie peste OAuth 2.0 pentru autentificarea utilizatorului. OIDC adaugă un ID Token în format JWT care conține informații despre utilizator (nume, email, id). Fluxul OAuth 2.0 + OIDC include: redirecționarea utilizatorului către pagina de login, obținerea unui cod de autorizare, schimbul codului pe tokenuri (access + refresh + id), utilizarea tokenului de acces pentru cereri API.

JWT: Tokenuri de Acces, Reîmprospătare și Sesiune

JWT (JSON Web Token) este un format de token compact și sigur pentru URL care conține claims în format JSON. JWT constă din trei părți: antet (tip și algoritm de semnare), payload (date) și semnătură. Tokenul de Acces este un token de scurtă durată (15-60 de minute) pentru acces API. Tokenul de Reîmprospătare este un token de lungă durată (zile/săptămâni) pentru obținerea unui nou token de acces fără reautentificare.

Tokenul de Sesiune este o abordare tradițională în care serverul stochează sesiunea într-o bază de date sau Redis, iar clientul primește un identificator aleator. În dezvoltarea mobilă, JWT este preferat: nu necesită stocarea sesiunii pe partea serverului, conține toate informațiile în sine și este ușor de verificat. Cu toate acestea, JWT nu poate fi revocat instantaneu — acesta este un compromis care se rezolvă prin durata scurtă de viață a tokenului de acces și utilizarea tokenurilor de reîmprospătare.

Autentificare Biometrică

Face ID și Touch ID pe iOS, Autentificare cu Amprentă pe Android — metode de autentificare biometrică care utilizează caracteristici fizice unice ale utilizatorului. Pe iOS, biometria funcționează prin LocalAuthentication (LAContext), pe Android — prin BiometricPrompt (Android 9+) sau FingerprintManager (învechit). Biometria este utilizată pentru deblocarea aplicației, confirmarea plăților și accesul la date protejate.

Nuanțe importante: biometria este o experiență de utilizare convenabilă, dar nu înlocuiește autentificarea pe server. După verificarea biometrică reușită, aplicația ar trebui să obțină un token de acces de la server. Pe Android, asigurați-vă că verificați dacă dispozitivul utilizează biometrie de Clasa 3 (Puternică), nu doar recunoaștere facială bazată pe cameră (Clasa 1).

Protecția Codului: ProGuard, R8 și Root Detection

Ofuscare: ProGuard și R8

ProGuard este un instrument de ofuscare, comprimare și optimizare a bytecode-ului Java pentru Android, care îmbunătățește securitatea codului împotriva ingineriei inverse. R8 este succesorul său, integrat în Gradle din Android Studio 3.4. R8 îndeplinește patru sarcini: comprimare (elimină clasele și metodele neutilizate), optimizare (inlinează metode, simplifică codul), ofuscare (redenumeste clasele și metodele în nume scurte) și pre-verificare (verificare bytecode).

DexGuard este o versiune comercială a ProGuard cu protecție avansată: criptare de șiruri, ofuscare de resurse, protecție împotriva repachetării, controlul integrității APK. Pentru majoritatea proiectelor, R8 este suficient, dar pentru aplicațiile financiare și bancare, DexGuard oferă un strat suplimentar de securitate. R8 se activează prin build.gradle: minifyEnabled = true și proguardFiles.

Detectare Root și Jailbreak

Root Detection (Android) și Jailbreak Detection (iOS) sunt mecanisme care verifică dacă au fost obținute privilegii de superutilizator pe dispozitiv. Pe dispozitivele compromise, se poate citi memoria procesului, intercepta traficul și substitui codul. Pentru verificarea pe Android, se utilizează prezența fișierului binar SU, chei de semnare de test și flaguri de compilare non-standard.

RASP (Runtime Application Self-Protection) este o tehnologie care protejează aplicația în timpul execuției. RASP detectează încercările de depanare, repachetare, injectare de cod și termină aplicația atunci când sunt detectate amenințări. Exemple de soluții RASP: Dexter, Guardsquare, Promon. RASP funcționează în timpul execuției și reacționează la anomalii — spre deosebire de ofuscarea statică, care protejează codul înainte de execuție.

Ingineria Inversă este procesul de recuperare a codului sursă dintr-o aplicație compilată. Instrumente: JADX (decompilator APK), Ghidra, IDA Pro, Hopper. Protecția împotriva Ingineriei Inverse este o combinație de ofuscare, criptare de șiruri, verificare a integrității și Root Detection. Nu există protecție completă — scopul este de a face ingineria inversă suficient de costisitoare pentru atacator.