Cuprins
- Ce înseamnă pentestul unei aplicații mobile
- Cele 8 grupuri MASVS
- Profilurile MAS: cât de strict se testează
- Ce profil vi se potrivește
- Riscurile principale: listele OWASP pentru mobil și API
- Ce contează pe fiecare platformă
- Pinning, root și ofuscare: ce protejează și ce nu
- Plățile mobile și BNM
- Cum decurge un pentest mobil
- Întrebări frecvente
- Surse
În 30 de secunde
- Standardul de referință e OWASP MASVS v2.1.0 (ianuarie 2024): 8 grupuri și 24 de controale, de la stocarea datelor la confidențialitate 12.
- Testele sunt în MASTG v2.0.0 (iulie 2026), prima versiune stabilă a cadrului refăcut: 285 de teste legate de controale prin slăbiciunile MASWE 37.
- Nivelurile vechi L1/L2/R au devenit profiluri MAS: L1, L2, R și P. Pentru o aplicație bancară, exemplul OWASP e L2+P+R 4.
- Detecția root/jailbreak și ofuscarea sunt apărare în adâncime, nu control de securitate: lipsa lor nu e în sine o vulnerabilitate 6.
- Atacatorul care controlează telefonul ajunge oricum la server: de aceea API-ul din spate intră mereu în test 1013.
Ce înseamnă pentestul unei aplicații mobile
O aplicație mobilă are două jumătăți: codul care rulează pe telefonul utilizatorului — deci în mâinile oricui o descarcă — și serverele cu care vorbește. Testul le acoperă pe amândouă. OWASP ghidul de testare spune că analiza dinamică privește atât aplicația de pe platforma mobilă, cât și serviciile și API-urile din spate, și recomandă accesul la codul sursă; testarea „gray-box” e cea mai răspândită 9.
| Proiectul OWASP MAS | Ce este | Versiunea |
|---|---|---|
| MASVS | Standardul: ce trebuie să îndeplinească aplicația — 8 grupuri, 24 de controale | v2.1.0, 18.01.2024 2 |
| MASWE | Catalogul slăbiciunilor: 78, legate de controale | v1.0.0, 17.08.2026 7 |
| MASTG | Ghidul de testare: 285 de teste, cu tehnici, unelte și demonstrații; fiecare test are criteriu clar de trecut sau picat | v2.0.0, iulie 2026 3 |
Cele 8 grupuri MASVS
Deschideți fiecare grup: ce cere standardul și ce verifică testerul în practică 12.
STORAGEStocarea datelorMASVS-STORAGE-1–2
- Ce cere
- Datele sensibile de pe telefon sunt stocate sigur și nu scapă în jurnale, copii de rezervă sau capturi.
- Ce verificăm
- Ce rămâne pe dispozitiv după autentificare și după deconectare: fișiere, baze locale, Keychain sau Keystore, jurnale.
CRYPTOCriptografieMASVS-CRYPTO-1–2
- Ce cere
- Criptografie actuală, folosită corect, și chei gestionate pe tot ciclul lor de viață.
- Ce verificăm
- Algoritmi, moduri, chei scrise în cod sau ușor de extras din aplicație.
AUTHAutentificare și autorizareMASVS-AUTH-1–3
- Ce cere
- Protocoale sigure cu serverul, autentificare locală (biometrie) folosită corect și pași suplimentari pentru operațiunile sensibile.
- Ce verificăm
- Dacă biometria doar „deblochează un ecran” sau chiar o cheie; dacă serverul verifică singur drepturile, nu aplicația.
NETWORKComunicarea în rețeaMASVS-NETWORK-1–2
- Ce cere
- Traficul e protejat, iar unde e nevoie, aplicația fixează identitatea serverelor proprii (pinning).
- Ce verificăm
- Interceptarea traficului, validarea certificatelor, excepțiile din ATS și din configurația de rețea Android.
PLATFORMInteracțiunea cu platformaMASVS-PLATFORM-1–3
- Ce cere
- Comunicarea cu alte aplicații (IPC), WebView-urile și interfața sunt folosite sigur.
- Ce verificăm
- Componente Android exportate, legături profunde, punți JavaScript în WebView, date vizibile în ecranele de fundal.
CODECalitatea coduluiMASVS-CODE-1–4
- Ce cere
- Platformă la zi, actualizări forțate când e nevoie, componente fără vulnerabilități cunoscute, intrări validate.
- Ce verificăm
- Biblioteci și SDK-uri de terți, versiunea minimă de sistem, ce se întâmplă cu datele neașteptate.
RESILIENCERezistență la inginerie inversăMASVS-RESILIENCE-1–4
- Ce cere
- Integritatea platformei, protecția la modificare și îngreunarea analizei statice și dinamice — ca apărare în adâncime.
- Ce verificăm
- Cât de repede se ocolesc detecția root/jailbreak, verificările de integritate și protecțiile împotriva depanării.
PRIVACYConfidențialitateMASVS-PRIVACY-1–4
- Ce cere
- Minimizarea datelor, neidentificarea, transparența și controlul utilizatorului asupra datelor lui.
- Ce verificăm
- Ce colectează aplicația și SDK-urile ei față de ce declară în magazin și în politica de confidențialitate.
Profilurile MAS: cât de strict se testează
Din MASVS v2.0.0, nivelurile nu mai sunt în standard: au devenit profiluri de testare, aplicate testelor din MASTG 24. Profilul se alege după cine e atacatorul.
| Profil | Cine e atacatorul |
|---|---|
| MAS-L1 Essential | Celelalte aplicații de pe telefon; sistemul de operare e intact 4 |
| MAS-L2 Advanced | Sistemul de operare nu e de încredere; acces fizic posibil. Recomandat aplicațiilor care ating date de card sau mută bani 5 |
| MAS-R Resilient | Utilizatorul însuși: cel care face inginerie inversă sau trișează 4 |
| MAS-P Privacy | Nu e centrat pe atacator: protecția datelor personale 4 |
Profilurile se combină. OWASP dă ca exemple L1+P, L1+P+R, L2+P și L2+P+R — ultima pentru aplicațiile bancare 4.
Ce profil vi se potrivește
Ce profil MAS vi se potrivește?
Orientativ, după profilurile OWASP MAS. Profilul final îl stabilim împreună, după modelul de amenințare.
MAS-L1 + MAS-P
- MAS-L1 — securitate esențială: celelalte aplicații de pe telefon sunt adversari, sistemul de operare e considerat intact.
- MAS-L2 — securitate avansată: sistemul de operare nu e de încredere, atacatorul poate avea acces fizic la telefon. OWASP îl recomandă aplicațiilor financiare.
- MAS-P — confidențialitate de bază: ce date colectează aplicația și SDK-urile ei, și dacă utilizatorul le controlează.
- MAS-R — rezistență: utilizatorul însuși poate fi atacatorul; testăm cât rezistă aplicația la inginerie inversă și modificare — în plus față de L1/L2, nu în locul lor.
Verificăm toate cele 8 grupuri MASVS; profilul decide cât de strict.
- API-ul din spate intră în perimetru: cererile aplicației se reiau și se modifică direct, fără aplicație.
- Android: componente exportate, WebView, configurația de rețea, Keystore, verdictele Play Integrity verificate pe server.
- iOS: excepțiile ATS, Keychain, schemele URL, App Attest verificat pe server.
- Două platforme înseamnă două aplicații de testat; API-ul comun se testează o singură dată.
Riscurile principale: listele OWASP pentru mobil și API
Lista de conștientizare pentru aplicațiile mobile, în versiunea finală din 2024 12:
- M1 Folosirea greșită a credențialelor (Improper Credential Usage)
- M2 Securitatea insuficientă a lanțului de aprovizionare
- M3 Autentificare și autorizare nesigure
- M4 Validarea insuficientă a intrărilor și ieșirilor
- M5 Comunicare nesigură
- M6 Controale de confidențialitate inadecvate
- M7 Protecția insuficientă a binarului
- M8 Configurare de securitate greșită
- M9 Stocarea nesigură a datelor
- M10 Criptografie insuficientă
Pentru serverele din spate se aplică API Security Top 10 — 2023, care numește explicit aplicațiile mobile. Pe primul loc stă BOLA — autorizarea la nivel de obiect: schimbi un ID în cerere și primești datele altui client 13.
Ce contează pe fiecare platformă
| Platforma | Subiectul | Ce spune documentația oficială |
|---|---|---|
| Android | Componente exportate | Cu android:exported="true", orice aplicație poate lansa componenta; atributul trebuie declarat explicit 14 |
| Android | WebView | addJavascriptInterface expune obiectul nativ tuturor cadrelor din WebView, fără verificarea originii 15 |
| Android | Configurația de rețea | Trafic necriptat interzis implicit de la Android 9; de la API 24, încredere implicită doar în autoritățile de certificare de sistem 16 |
| Android | Play Integrity | Verdicte despre aplicație, dispozitiv și cont; Google cere să nu fie singurul mecanism anti-abuz, iar nonce-ul se gestionează pe server 17 |
| iOS | App Transport Security | Activ implicit; cere TLS 1.2 sau mai nou; unele excepții cer justificare la publicarea în App Store 18 |
| iOS | Keychain | Baza criptată pentru „bucăți mici de date”: parole, chei, certificate 19 |
| iOS | App Attest | Cheie generată în Secure Enclave și certificată de Apple; verificarea se face pe server, iar nu toate dispozitivele îl suportă 20 |
Pinning, root și ofuscare: ce protejează și ce nu
Pinning-ul leagă aplicația de certificatul serverelor proprii. MASTG spune că lipsa lui nu trebuie raportată ca vulnerabilitate, dar că e obligatoriu pentru MAS-L2; și că un atacator care controlează dispozitivul îl poate dezactiva, deci nu protejează serverul 10. Când aplicația folosește API-urile standard, ocolirea durează câteva secunde cu unelte ca Frida sau objection — de aceea testerii o fac primii, ca să vadă traficul 11. Apple scria în 2021 că, în cele mai multe cazuri, pinning-ul nu e necesar 21.
Plățile mobile și BNM
Pentru plăți, autentificarea strictă a clienților cere ca elementele de autentificare să fie independente. Când telefonul e un „dispozitiv universal” — pe care rulează și aplicația, și primirea codului — sunt obligatorii medii de execuție separate, mecanisme care confirmă că software-ul sau dispozitivul nu au fost modificate și atenuarea consecințelor dacă au fost (RTS (UE) 2018/389, art. 9) 22. În Republica Moldova, regulamentul BNM privind autentificarea strictă (HCE nr. 12/2024) reproduce aceste cerințe la pct. 16–17 23.
Regulamentul TIC al BNM cere teste de penetrare pe sistemele critice cel puțin o dată la 3 ani și testare de securitate la lansarea sistemelor noi accesibile din internet (pct. 33.2, 33.5) — o aplicație de mobile banking intră în ambele 24. Testul pe profilul MAS-L2 răspunde direct mecanismelor anti-modificare cerute de art. 9.
Magazinele cer și ele transparență: Google Play cere tuturor aplicațiilor secțiunea Data safety, inclusiv pentru SDK-urile terților 25, iar Apple cere motivul declarat pentru API-urile cu „motiv obligatoriu” în manifestul de confidențialitate 26. Profilul MAS-P verifică dacă ce declarați corespunde cu ce colectează aplicația.
Cum decurge un pentest mobil
- Profilul și perimetrul
Stabilim profilul MAS, platformele, versiunile și API-urile din spate; primim build-uri de test și conturi pentru fiecare rol.
- Analiză statică
Decompilare și revizuire: chei în cod, componente exportate, configurația de rețea, biblioteci cu vulnerabilități cunoscute.
- Analiză dinamică
Aplicația rulând pe dispozitive de test: interceptarea traficului, ce rămâne stocat, comportamentul la root/jailbreak.
- API-ul din spate
Cererile reluate fără aplicație: autorizarea la nivel de obiect și de funcție, autentificarea, limitele.
- Raport și re-test
Fiecare constatare cu controlul MASVS, gravitatea, dovada și remedierea; re-testul pe noul build închide constatările.
Întrebări frecvente
Ce standard se folosește pentru pentestul aplicațiilor mobile?
Ce înseamnă MAS-L1, MAS-L2, MAS-R și MAS-P?
Lipsa pinning-ului este o vulnerabilitate?
Detecția root/jailbreak ne protejează aplicația?
Testați și API-ul din spatele aplicației?
Surse
Fiecare afirmație despre lege sau standard trimite la sursa ei oficială. Consultate la data indicată.
- OWASP MASVS — standardul de verificare a securității aplicațiilor mobile (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MASVS v2.1.0 (18.01.2024) — versiunea și controalelegithub.com · consultat 23 octombrie 2026
- „MASTG v2.0.0 is Here” — anunțul OWASP MAS (04.07.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MAS — profilurile de testare (MAS-L1, MAS-L2, MAS-R, MAS-P) (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MAS — profilul MAS-L2 (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MASVS-RESILIENCE (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MASWE v1.0.0 (17.08.2026) — slăbiciunile aplicațiilor mobilegithub.com · consultat 23 octombrie 2026
- OWASP MAS — retragerea listei de verificare (14.07.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MASTG — testarea securității aplicațiilor mobile (analiză statică și dinamică) (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MASTG — testarea comunicațiilor de rețea (pinning) (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP MASTG-TECH-0012 — ocolirea pinning-ului pe Android (accesat 23.10.2026)mas.owasp.org · consultat 23 octombrie 2026
- OWASP Mobile Top 10 (2024)owasp.org · consultat 23 octombrie 2026
- OWASP API Security Top 10 — 2023owasp.org · consultat 23 octombrie 2026
- Android — riscul android:exporteddeveloper.android.com · consultat 23 octombrie 2026
- Android — punțile native nesigure din WebViewdeveloper.android.com · consultat 23 octombrie 2026
- Android — configurația de securitate a rețeleideveloper.android.com · consultat 23 octombrie 2026
- Android — prezentarea Play Integrity APIdeveloper.android.com · consultat 23 octombrie 2026
- Apple — prevenirea conexiunilor de rețea nesigure (ATS)developer.apple.com · consultat 23 octombrie 2026
- Apple — Keychain Servicesdeveloper.apple.com · consultat 23 octombrie 2026
- Apple — verificarea integrității aplicației (App Attest)developer.apple.com · consultat 23 octombrie 2026
- Apple Developer News — despre identity pinning (14.01.2021)developer.apple.com · consultat 23 octombrie 2026
- Regulamentul delegat (UE) 2018/389 (RTS privind autentificarea strictă a clienților)eur-lex.europa.eu · consultat 23 octombrie 2026
- BNM — Regulamentul cu privire la autentificarea strictă a clienților (HCE nr. 12/2024)bnm.md · consultat 23 octombrie 2026
- BNM — Regulamentul privind cerințele minime pentru gestionarea riscurilor TIC (HCE nr. 29/2025)bnm.md · consultat 23 octombrie 2026
- Google Play — secțiunea Data safetysupport.google.com · consultat 23 octombrie 2026
- Apple — API-urile cu motiv obligatoriu în manifestul de confidențialitatedeveloper.apple.com · consultat 23 octombrie 2026
Despre autori
Ghidurile le scrie echipa care face testele, nu un departament de marketing. Le actualizăm când se schimbă legea, standardul sau ce vedem în teste.