Sicurezza Mobile | Pentest | Fintech

Sicurezza Mobile nelle Fintech: cosa trova un pentest nell'app che il tuo scanner non vede mai

09 ago 2026· 12 min di lettura· Livello: Intermedio

Categoria: Sicurezza Mobile | Pentest | Fintech Livello: Intermedio Ambiente: Laboratorio controllato — scenario totalmente anonimizzato, senza dati reali di clienti

Introduzione

La tua app bancaria è sul Play Store con 4,8 stelle. Il team di ingegneria fa code review, la pipeline esegue SAST a ogni push e il backend è passato da una scansione automatizzata nell'ultima release. Eppure, quando inizia un pentest mobile, la prima cosa che il tester trova di solito sorprende: i problemi più gravi non sono nel backend — sono nell'app che hai pubblicato.

Le fintech trattano il tipo di asset che gli avversari inseguono di più: denaro, dati bancari, token di sessione e PII in volume. Lo smartphone è diventato l'interfaccia principale di questo flusso, e la sicurezza mobile ha una caratteristica unica: il codice dell'app è nella tasca dell'attaccante. A differenza del backend, che proteggi dietro firewall e WAF, l'APK/IPA viene distribuito a milioni di dispositivi — chiunque può scaricarlo, decompilarlo e studiare la tua app come si legge un libro aperto.

Questo materiale è preventivo e descrive, in uno scenario di laboratorio anonimizzato, cosa ha trovato un pentest mobile in una fintech fittizia ("PayFlow") — e perché ogni finding rappresenta un rischio reale per qualsiasi azienda che muove denaro tramite app.

1. Perché la sicurezza mobile è diversa (la fisica del problema)

Prima dei finding, vale la pena capire perché l'app richiede un approccio proprio:

L'attaccante ha il binario. Il backend è una scatola nera; l'app è una scatola bianca. Con jadx, apktool o MobSF, chiunque trasforma un APK in codice leggibile in pochi minuti. Un segreto che vive nell'app non è un segreto — è un conto alla rovescia.
Il dispositivo è ostile. L'app gira in un ambiente che l'utente controlla: con root, con hooking (Frida), con un proxy che intercetta il traffico. Se l'app si fida del dispositivo, l'attaccante controlla l'app.
L'API mobile è una superficie parallela. Molte fintech mantengono endpoint specifici dell'app con controlli più deboli di quelli web — e versioni vecchie dell'API restano attive anni dopo.
Il danno è diretto. La fuga di un token di sessione, il bypass dell'autenticazione o una chiave API esposta in una fintech significano accesso al saldo, ai trasferimenti e ai dati bancari — non solo "esposizione dell'infrastruttura".

L'OWASP Mobile Top 10 (2024) organizza bene ciò che si ripete di più nei test reali: uso improprio delle credenziali (M1), comunicazione insicura (M5), autenticazione/autorizzazione insicure (M3), archiviazione insicura dei dati (M9) e protezioni binarie insufficienti (M7) — esattamente i pattern che i finding seguenti riproducono.

2. Lo scenario di laboratorio: la fintech "PayFlow"

Per mostrare il flusso completo, abbiamo usato uno scenario fittizio di laboratorio: PayFlow, fintech di pagamenti con 2 milioni di utenti attivi, app Android e iOS, che muove Pix, carte e conti digitali. Ha commissionato un pentest mobile con la seguente indicazione: testare l'app come farebbe un avversario reale — scaricare l'APK, decompilare, analizzare staticamente e poi attaccare l'API dietro l'app con un proxy.

Il risultato: otto finding, tutti con riproduzione, tutti classificati in base all'impatto reale per il business. Di seguito, i cinque più rappresentativi.

3. I finding (scenario anonimizzato)

Finding 1 — [CRITICO] Chiave API e segreto di firma hardcoded nell'APK

Nell'analisi statica dell'APK (jadx + apkleaks), il tester ha trovato una API key di un servizio di pagamento di terze parti e il segreto usato per firmare i token JWT incorporati nel codice, in una classe di configurazione.

Riproduzione: estrazione dell'APK dal Play Store → decompilazione → stringhe/costanti in chiaro.
Perché accade: il team aveva bisogno di un modo semplice per autenticare l'app contro il servizio e ha "nascosto" il segreto nel codice del client, credendo che l'offuscamento bastasse.
Impatto: con il segreto di firma, un attaccante forgia token JWT e si spaccia per qualsiasi utente — inclusi gli utenti amministrativi, se il backend non distingue il token dell'app dal token admin. La chiave di terze parti consente di spendere il credito del servizio di pagamento a nome di PayFlow.
Lezione: un segreto che deve vivere nel backend non può vivere nell'app. Qualsiasi credenziale incorporata è, per definizione, pubblica.
OWASP Mobile Top 10 (2024): M1 (Improper Credential Usage) + M7 (Insufficient Binary Protections) — l'offuscamento non è controllo degli accessi.

Finding 2 — [ALTO] Nessun certificate pinning: traffico intercettabile via proxy

L'app validava solo la catena di certificati del sistema operativo — senza certificate pinning. Il tester è riuscito a intercettare il traffico in due modi: l'installazione della CA di Burp Suite sul dispositivo ha funzionato perché l'app si fidava delle CA utente (comune nelle build di sviluppo o con networkSecurityConfig permissivo); nelle app Android moderne (targetSdk ≥ 24), che non si fidano delle CA utente per impostazione predefinita, il percorso reale è il bypass via Frida.

Riproduzione: proxy sulla rete → installazione della CA (build di sviluppo/networkSecurityConfig permissivo) o bypass via Frida → traffico dell'app decodificato in Burp.
Perché accade: il pinning complica lo sviluppo (certificati di staging, test in CI) e il team ha rimandato l'implementazione.
Impatto: in uno scenario reale, lo stesso traffico intercettato contiene token di sessione e payload con dati bancari. Il pinning non è una difesa assoluta (un attaccante con accesso al dispositivo usa Frida per aggirarlo), ma alza il costo dell'attacco e impedisce l'intercettazione passiva sulle reti pubbliche — la porta d'ingresso più comune.
Lezione: il pinning è igiene di base per un'app che muove denaro; senza, l'app dipende interamente dal TLS del sistema operativo.
OWASP Mobile Top 10 (2024): M5 (Insecure Communication).

Finding 3 — [ALTO] Token di sessione e dati bancari memorizzati in chiaro sul dispositivo

L'analisi dinamica (dispositivo con root + Frida) ha rivelato che l'app conservava il token di sessione e l'ultimo estratto conto consultato in SharedPreferences e in file SQLite in chiaro — senza crittografia, senza Keychain/Keystore.

Riproduzione: navigare nell'app → ispezionare /data/data/<pacchetto>/shared_prefs e il SQLite locale.
Perché accade: memorizzare il token in memoria persistente è stata la soluzione rapida per mantenere l'utente connesso senza ri-autenticarlo a ogni apertura.
Impatto: un dispositivo compromesso (malware/root), o un telefono smarrito/rubato senza blocco schermo/FBE o con allowBackup=true (estrazione via adb backup), consegna il token di sessione — e, con esso, l'accesso all'account senza bisogno della password. I dati bancari memorizzati localmente amplificano il danno di un semplice furto del telefono.
Lezione: i token devono vivere nell'archiviazione sicura del sistema operativo (Keystore/Keychain), con breve durata; i dati sensibili non devono essere persistiti sul dispositivo senza necessità — e, se lo sono, crittografati con una chiave derivata dal Keystore.
OWASP Mobile Top 10 (2024): M9 (Insecure Data Storage).

Finding 4 — [ALTO] Endpoint API mobile con controlli più deboli di quelli web

L'app parlava con un'API dedicata (api-mobile.payflow.app) che non imponeva gli stessi controlli dell'API web: rate limiting assente, nessuna validazione della versione dell'app e risposte con più dati di quelli necessari allo schermo (es.: l'endpoint del saldo restituiva anche lo storico completo delle transazioni e il CPF completo dell'utente).

Riproduzione: l'analisi statica ha rivelato l'endpoint; il proxy ha mostrato il payload completo della risposta.
Perché accade: l'API mobile è stata creata dopo, da un altro team, con la fretta di lanciare — e nessuno ha verificato se i controlli dell'API web valessero anche per lei.
Impatto: l'assenza di rate limiting apre la strada a enumerazione degli account e attacchi di forza bruta; l'eccesso di dati nelle risposte trasforma un endpoint legittimo in fonte di esfiltrazione per un attaccante con un token rubato (o in uno scenario di accesso indebito).
Lezione: l'API mobile non è un'API diversa — è la stessa superficie di rischio, con l'aggravante di essere facilmente scopribile dalla stessa app.
OWASP Mobile Top 10 (2024): M3 (Insecure Authentication/Authorization) — rate limiting assente ed eccesso di dati nelle risposte aggravano l'M3.

Finding 5 — [MEDIO] Deep link manipolabili (apertura di schermate sensibili senza validazione dell'origine)

L'app registrava deep link (payflow://transferencia?valor=...) e li apriva senza validare l'origine dell'intent/URL scheme. In uno scenario di attacco, un link dannoso inviato via SMS o da un sito compromesso poteva aprire schermate di trasferimento precompilate all'interno dell'app autenticata.

Riproduzione: adb shell am start -a android.intent.action.VIEW -d "payflow://transferencia?valor=9999" su un dispositivo con l'app connessa.
Perché accade: i deep link sono stati implementati per le campagne di marketing e nessuno ha considerato il vettore di abuso.
Impatto: la superficie è di ingegneria sociale — l'app autenticata esegue un'azione sensibile a partire da un trigger esterno. Il rischio reale dipende dalla validazione dei parametri e dalla conferma a schermo, ma l'apertura diretta di flussi sensibili via link è un pattern che va bloccato.
Lezione: i deep link richiedono allowlist di domini (App Links/Universal Links), validazione dei parametri e, per le azioni sensibili, conferma esplicita dell'utente.
OWASP Mobile Top 10 (2024): M4 (Insufficient Input/Output Validation) — superficie di ingresso non validata da origini esterne.

4. Perché lo scanner da solo non trova questo

I finding precedenti condividono un pattern comune: nessuno dipende da una vulnerabilità classica del backend (SQLi, RCE, XSS). Sono difetti di design dell'app e di logica di business:

Finding	Tipo di test che lo trova
Segreto hardcoded	Analisi statica del binario (jadx/apkleaks/MobSF) — lo scanner di infrastruttura non guarda l'APK
Assenza di pinning	Test manuale con proxy + dispositivo reale
Archiviazione insicura	Analisi dinamica con dispositivo root + Frida
API mobile con controlli deboli	Reverse engineering + test funzionale dell'API — richiede conoscere il flusso dell'app
Deep link abusabili	Test manuale di intent/URL scheme

Una scansione automatizzata del backend non scarica l'app, non decompila, non gira sul dispositivo e non intercetta il traffico. Per la sicurezza mobile, lo scanner è solo l'inizio — la parte che trova i problemi è il lavoro manuale guidato dal ragionamento avversariale: "se fossi l'attaccante con l'APK in mano, cosa farei?".

5. Cosa include un programma di sicurezza mobile maturo (checklist pratica)

Sulla base dello scenario precedente, il minimo che una fintech dovrebbe avere nel proprio programma mobile:

Analisi statica automatizzata in CI (MobSF, semgrep per Android/iOS) — cattura segreti, permessi eccessivi, componenti esportati e WebView insicure a ogni build.
Gestione rigorosa dei segreti — nessuna credenziale nel binario; segreti nel backend, ruotati, con rilevamento delle fughe (gitleaks e simili nel repository).
Certificate pinning nell'app di produzione, con piano di rotazione e bypass solo nelle build di sviluppo.
Archiviazione sicura — token in Keystore/Keychain, dati sensibili non persistiti senza necessità, FLAG_SECURE sulle schermate sensibili (blocco degli screenshot).
API mobile trattata come superficie di rischio propria — stesso rigore di autenticazione, rate limiting ed esposizione minima dei dati; versioni vecchie dismesse.
Pentest mobile periodico (a ogni release rilevante o almeno annuale) con analisi statica + dinamica + test dell'API — eseguito da chi conosce il flusso del business, non solo da uno strumento.
Formazione del team — i finding più comuni (hardcoded secrets, archiviazione insicura) sono fallimenti di abitudine, non di tecnologia.

6. Perché commissionare un pentest mobile (e non "uno scanner")

Il valore del pentest mobile non sta nel "eseguire uno strumento" — sta nella lettura avversariale di un binario che chiunque può scaricare. Per una fintech, il costo di un finding critico non corretto si misura in saldo dei clienti e in fiducia regolatoria: la Banca Centrale brasiliana (Bacen) osserva la gestione della sicurezza delle istituzioni di pagamento, e gli incidenti con dati bancari hanno conseguenze che vanno oltre la riparazione tecnica.

Lo scenario PayFlow è di laboratorio — ma ciascuno degli otto finding riproduce pattern che si ripetono nelle app reali del mercato finanziario. La differenza tra la fintech che lo scopre in un test e quella che lo scopre in un incidente è esattamente il valore del pentest.

Questo articolo descrive uno scenario di laboratorio totalmente fittizio, costruito a scopo educativo. Nessun dato reale di clienti è stato utilizzato. Lo sfruttamento di vulnerabilità in sistemi senza autorizzazione esplicita è illegale.