𝗔𝘁𝘁𝗮𝗰𝗰𝗵𝗶 𝗮𝗹𝗹𝗮 𝗟𝗼𝗴𝗶𝗰𝗮 𝗱𝗶 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗦𝗽𝗶𝗲𝗴𝗮𝘁𝗶
Gli attaccanti non sempre violano il codice per rubare denaro.
Molti sviluppatori trascorrono mesi a mettere in sicurezza API e crittografia. Si concentrano sul prevenire SQL injection o XSS. Poi, un attaccante ruba fondi senza violare un singolo controllo di sicurezza.
Questo è un attacco alla logica di business.
L'applicazione funziona esattamente come progettato. L'attaccante usa semplicemente le tue stesse regole contro di te.
Pensa a una cassaforte bancaria. La maggior parte dei test di sicurezza verifica se la porta è robusta. Il testing della logica di business pone una domanda diversa. E se qualcuno convincesse la guardia ad aprire la porta per lui?
La cassaforte funziona. Il processo fallisce.
Ecco tre modi in cui gli attaccanti abusano della logica bancaria:
Aggiramento dei periodi di attesa Le banche spesso richiedono un'attesa di 24 ore dopo l'aggiunta di un nuovo destinatario. Questo previene i furti rapidi. Un attaccante potrebbe trovare un endpoint API che salta questo controllo. Aggira la restrizione dell'interfaccia utente (UI) e sposta il denaro istantaneamente.
Violazione dei limiti di transazione Una banca potrebbe impostare un limite giornaliero di 50.000. Se il codice controlla solo ogni singola transazione, un attaccante può inviare cinque trasferimenti da 49.000. Ogni transazione appare valida. La somma totale supera il limite, ma il sistema non se ne accorge.
Abuso dei premi Molte app offrono cashback per il pagamento delle bollette. Un attaccante potrebbe pagare una bolletta e poi cancellarla immediatamente. Se il sistema non revoca il premio, l'attaccante crea un ciclo per accumulare cashback infinito.
Perché gli scanner automatizzati non rilevano questo?
Gli scanner cercano falle tecniche come malware o injection. Uno scanner vede un trasferimento riuscito e restituisce uno stato 200 OK. Pensa che tutto vada bene.
Un tester umano si chiede: questo trasferimento avrebbe dovuto avvenire affatto?
Per trovare queste falle, smetti di chiederti se una funzionalità può essere hackerata. Inizia a chiederti se una funzionalità può essere abusata.
Controlla queste aree:
- Gli utenti possono saltare i passaggi di verifica?
- Gli utenti possono cambiare la proprietà di un ID?
- I periodi di attesa possono essere aggirati tramite API?
- I limiti sono applicati sull'importo totale o solo per singola operazione?
- I premi possono essere attivati più volte?
I team di sicurezza d'élite non creano solo casi d'uso (use cases). Creano casi d'abuso (abuse cases).
Invece di testare "L'utente trasferisce denaro", testa "L'attaccante tenta 500 piccoli trasferimenti per aggirare i limiti".
La seconda domanda individua il rischio reale.
Fonte: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj