Pentest di app bancarie | Abuso di account di test e pagamenti

Che cosa comporta per il suo test

Un penetration test di un’app bancaria deve seguire il percorso del cliente attraverso il dispositivo, il servizio di identità e l’API di backend. Includete il recupero dell’account, la registrazione dei dispositivi, le modifiche dei beneficiari e l’autorizzazione dei pagamenti. Predisponete coppie di ruoli per clienti e personale, così che la valutazione possa distinguere un’azione consentita da un errore nei controlli di titolarità o approvazione.

Un flusso bancario. Diversi perimetri di sicurezza.

Un test di penetrazione di un’app bancaria è una valutazione di sicurezza autorizzata dell’applicazione mobile o web di una banca e dei servizi backend che la supportano. Verifica se qualcuno può accedere alle informazioni di un altro cliente, abusare di una sessione o eseguire un’operazione al di fuori delle proprie autorizzazioni. L’ambito concordato può includere il retail banking, i servizi bancari per le imprese o una specifica versione di prodotto.

Atlant Security collega i test delle applicazioni mobili alle autorizzazioni di clienti, personale e servizi coinvolti in ogni flusso. La domanda concreta è: il server riesce ancora ad applicare le regole della banca quando non ci si può più fidare del client, del dispositivo o della sessione?

Partite dalle vostre piattaforme, dai ruoli dei clienti e dai flussi di lavoro critici. Da questi elementi definiamo una proposta di ambito, condizioni operative e deliverable.

Cosa può coprire un penetration test di un’app bancaria

Selezionate i canali e i flussi di lavoro da valutare. Una build iOS, una build Android e un’API condivisa sono superfici di test distinte; includerne una non comporta automaticamente l’inclusione delle altre.

Per un incarico limitato alle API, consultate i test di penetrazione per il digital banking e le API. Per scenari più approfonditi di doppio controllo, rilascio dei pagamenti e riconciliazione, consultate i test dei flussi di pagamento.

Come testiamo il mobile banking e l’online banking

01 / Concordare l’autorizzazione e le condizioni del test

Registrare gli identificativi delle applicazioni, i numeri di build, i sistemi operativi supportati, le versioni API e le differenze tra ambienti. Definire i ruoli dei clienti, i flussi sensibili, le tecniche consentite, i limiti di frequenza e i contatti per interrompere i test. Concordare la disponibilità del codice sorgente, di una build di test o di credenziali fornite, nonché le modalità di documentazione di tale assistenza.

02 / Esaminare il cliente e le sue comunicazioni

Esaminate il pacchetto dell’app fornito e osservatene il comportamento sui dispositivi concordati. Analizzate il trattamento locale dei dati, le funzionalità della piattaforma e il traffico verso i servizi autorizzati. Se le misure di hardening dell’app limitano l’osservazione, concordate prima l’approccio di valutazione. Un aggiramento in una build di test modificata non viene presentato come un aggiramento dimostrato della build di produzione.

03 / Convalidare le regole della banca lato server

Eseguire flussi rappresentativi con identità di test separate. Confrontare le operazioni consentite e negate tra account, ruoli e stati delle transazioni. Convalidare manualmente le debolezze rilevanti e confermare le modifiche di stato tramite una rilettura indipendente o una registrazione di audit concordata. Il solo output dello strumento non dimostra l’impatto aziendale.

04 / Redigere il rapporto, correggere e ripetere il test

Descriva l’accesso dimostrato, i controlli efficaci e le aree non testate. Esamini i risultati con i team responsabili, quindi ripeta i test delle correzioni concordate sulla build modificata e sulla versione del backend. Le scadenze di rilascio, le finestre per i retest e le dipendenze fanno parte della proposta.

Esempio: modifica del beneficiario dopo l’approvazione

Progettazione di test illustrativa, non è un risultato ottenuto presso un cliente. Un cliente di servizi bancari per imprese crea un pagamento sintetico a favore di un beneficiario di test approvato. Un secondo utente autorizzato lo approva. La valutazione verifica se modifiche successive al beneficiario o all’importo invalidano tale approvazione e richiedono nuovamente l’autorizzazione prevista.

• Punto di partenza: identità dedicate di chi dispone e di chi verifica, un pagamento predisposto e un ambiente di test in cui il regolamento è disattivato.
• Risultato atteso: il server rifiuta una modifica non autorizzata oppure riporta l’istruzione allo stato di approvazione appropriato.
• Evidenze: versioni dell’app e dell’API, identità e ruolo, timestamp, richieste e risposte oscurate, stato risultante della transazione ed eventi di audit pertinenti.
• Limite: modificare una bozza non dimostra che i fondi possano essere svincolati. Il regolamento rimane disattivato e l’eventuale confine di firma a valle viene valutato solo se autorizzato.

Questo approccio fornisce ai team di ingegneria e di gestione del rischio un rilievo che possono convalidare, senza confondere una schermata accessibile, una risposta positiva e un pagamento completato.

Che cosa riceve il suo team

• Valutazione per la direzione: i percorsi bancari sottoposti a test, le conseguenze aziendali, i controlli che hanno retto e le decisioni prioritarie.
• Registro della copertura: applicazioni, build, ruoli, API, ambienti, ipotesi, esclusioni ed eventuali attività bloccate o incomplete.
• Rilievi tecnici: asset interessati, prerequisiti, osservazioni riproducibili, evidenze oscurate, motivazione della gravità e limiti del risultato.
• Indicazioni per la correzione: misure di protezione immediate, correzioni durature e criteri di accettazione per il team responsabile dello sviluppo o della piattaforma.
• Risultati dei test di verifica concordati: versioni modificate, casi ripetuti e rilievi confermati come risolti, risolti parzialmente, ancora aperti o non sottoposti a nuovo test.

Esaminate i deliverable dei report oppure visualizzate un’anteprima del report fittizio di Megabank AG. L’esempio illustra il formato più ampio dei report bancari; non costituisce prova di una valutazione reale del mobile banking.

Preparare l’ambito di un test delle applicazioni

Per la richiesta iniziale è sufficiente una descrizione generale. Utilizzi il generatore RFP per delineare sistemi, obiettivi e tempistiche, oppure invii un brief esistente con un NDA per la revisione tramite il modulo di contatto. Concordi un canale di trasferimento sicuro prima di condividere build, credenziali o dettagli architetturali sensibili.

• Piattaforme e release: iOS, Android, home banking web, versioni delle build e scadenza prevista per il rilascio o la verifica.
• Flussi: onboarding, accesso, recupero dell’account, accesso al conto, gestione dei beneficiari, trasferimenti, approvazioni e altre funzioni critiche.
• Ruoli: clienti retail, utenti aziendali, utenti delegati, approvatori, ruoli di supporto e relazioni di test rappresentative.
• Dipendenze: documentazione API, provider di identità, sandbox di pagamento, titolarità di terze parti e requisiti di autorizzazione.
• Condizioni operative: ambiente, dati sintetici, metodi consentiti, autorità di interruzione, contatti di monitoraggio e ripristino.
• Output: destinatari del rapporto, discussione delle remediation, necessità di retest e mappature richieste per approvvigionamento o assurance.

Durata e tariffe dipendono dal numero di build e ruoli, dalla complessità dei flussi di lavoro, dalla copertura delle API, dalle modalità di accesso e dai requisiti di reportistica. Una valutazione circoscritta a una release richiede un impegno diverso da un ambito completo per applicazioni mobili e web. Concordiamo queste ipotesi prima di formulare un preventivo.

Prepari un documento dettagliato di definizione dell’ambito oppure invii il Suo RFP allegando un NDA.

Domande sul pentest delle app bancarie

I test di mobile banking includono le API di backend?

L’ambito dovrebbe includere le operazioni API necessarie per valutare i flussi mobili concordati, registrando nell’ambito i servizi e gli endpoint esatti. Ulteriori insiemi di API, i sistemi interni del personale e altri canali richiedono decisioni separate sull’ambito. Il solo test del binario dell’app non consente di stabilire come il server applichi ogni autorizzazione.

Potete valutare sia iOS sia Android?

Sì. Indichi entrambe le piattaforme quando richiede la definizione dell'ambito. Le funzionalità condivise del prodotto non rendono identici l'archiviazione, le autorizzazioni, i collegamenti alle app e l'hardening specifici della piattaforma. La proposta registra le build e la copertura dei dispositivi o dei sistemi operativi.

È possibile eseguire i test in produzione?

Solo alle condizioni concordate esplicitamente. Per gli scenari di pagamento che modificano lo stato è utile un ambiente rappresentativo che non esegua il regolamento delle operazioni. Qualsiasi attività in produzione richiede un’autorizzazione scritta, identità e dati controllati, limiti operativi e la facoltà di interrompere l’attività. Il report registra le differenze che impediscono di presumere che un risultato ottenuto in staging sia valido anche in produzione.

Sono necessari il codice sorgente o account di test?

Gli account rappresentativi rendono generalmente più utili i test dei ruoli e dei confini tra clienti. Il codice sorgente e una build strumentabile possono aiutare a rispondere a domande specifiche, ma sono opzioni di ambito. La proposta distingue le attività non autenticate, autenticate e assistite e registra ciò che non può essere testato senza l'accesso richiesto.

È la stessa cosa di un penetration test della rete di una banca?

No. Questo servizio segue i percorsi delle applicazioni rivolti ai clienti dal dispositivo o dal browser fino alle API di supporto. Una valutazione della rete e dell’identità bancaria esamina l’infrastruttura e i percorsi di fiducia interni. I due servizi possono essere combinati quando l’obiettivo richiede entrambi.

Quando dovremmo richiedere un penetration test di un’app bancaria?

Pianificate con sufficiente anticipo per correggere i problemi e ripetere i test prima di una release significativa. Le nuove funzionalità di autenticazione, ripristino, pagamento o API possono modificare sostanzialmente l’ambito necessario. Concordate verifiche ricorrenti in base al ciclo di rilascio e al programma di gestione dei rischi, senza presumere che una valutazione copra tutte le versioni successive.

Riferimenti e copertura dei test

Utilizziamo le aree di controllo pertinenti di OWASP MASVS e le linee guida di test MASTG per strutturare la copertura mobile. La descrizione delle attività identifica i controlli e i casi di test applicabili; citare questi riferimenti non implica una certificazione OWASP né la copertura completa di tutti i controlli.

La selezione degli scenari API include l’autorizzazione a livello di oggetto e i flussi aziendali sensibili dell’OWASP API Security Top 10. Questi riferimenti aiutano a organizzare la valutazione; le regole proprie della banca in materia di account, ruoli e pagamenti determinano le decisioni attese.

Se l’incarico ha un obiettivo normativo, indicatelo durante la definizione dell’ambito e consultate le nostre indicazioni sui test bancari e sui requisiti normativi insieme al responsabile del programma.