Logica di business nelle web app: i bug che gli scanner automatici non vedono mai

Le vulnerabilità di logica di business sfruttano funzioni del tutto legittime di un’applicazione, usate in un ordine o in un contesto imprevisto. Non generano errori, quindi gli scanner automatici le ignorano. Eppure sono tra le falle più costose per un’azienda.

C’è una situazione che chi si occupa di sicurezza applicativa conosce bene. Il report dello scanner di vulnerabilità torna pulito, senza una segnalazione critica, eppure l’applicazione viene violata lo stesso. Non per una falla tecnica clamorosa ma per il modo in cui è stata pensata. Qualcuno ha usato le sue funzioni esattamente come previsto, soltanto in una sequenza o con valori che nessuno aveva immaginato.

1. Che cosa sono le vulnerabilità di logica di business
2. Perché gli scanner automatici non le vedono
3. Gli errori ricorrenti
4. Analisi della falla da 250.000 dollari di Coinbase
5. Come si difende davvero un’azienda

Questa famiglia di problemi prende il nome di vulnerabilità di logica di business. A differenza di una SQL Injection o di un cross-site scripting, qui non c’è un controllo di sicurezza rotto o assente. C’è una regola di funzionamento dell’applicazione che viene aggirata sfruttando funzionalità perfettamente lecite. È proprio questa natura a renderle quasi invisibili agli strumenti automatici e a farne il terreno di caccia preferito di chi cerca falle che valgono davvero.

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

Cosa sono le vulnerabilità di logica di business

Con logica di business si intende l’insieme delle regole che definiscono come un’applicazione deve comportarsi in una data situazione. Sono i vincoli pensati in fase di progetto, dal divieto di acquistare a prezzo negativo all’obbligo di completare un pagamento prima della spedizione. Una vulnerabilità di logica nasce quando un attaccante riesce a forzare un comportamento che il programma non avrebbe mai dovuto consentire, restando però dentro le sue funzioni legittime.

La differenza con le falle tecniche più note è sostanziale. La maggior parte dei problemi di sicurezza deriva da un controllo mancante o malfunzionante, dall’autenticazione alla validazione dell’input. Una vulnerabilità di logica, invece, abusa del flusso di lavoro previsto dall’applicazione e lo piega a un esito dannoso per l’azienda. La classificazione CWE-840 raccoglie proprio questi errori, mentre OWASP li tratta in una scheda dedicata e nel recente progetto Top 10 for Business Logic Abuse.

Proprio OWASP è autrice di una regola pratica per riconoscerle. Se per capire la falla serve conoscere davvero il funzionamento del business, con ogni probabilità si è davanti a un problema di logica e non a una vulnerabilità tecnica tradizionale.

Perché gli scanner automatici non le vedono

Uno scanner di vulnerabilità lavora per confronto. Conosce un catalogo di comportamenti sospetti, sequenze di caratteri pericolose, versioni di software con falle note, o configurazioni errate. Sono questi gli elementi che cerca dentro l’applicazione. È molto efficace su tutto ciò che assomiglia a un comportamento già visto e catalogato. Davanti alla logica di business questo metodo si ferma.

Una falla logica non lascia traccia di errore. L’applicazione non va in crash, non restituisce un messaggio anomalo, anzi spesso conferma l’operazione come se tutto fosse in regola. Per uno strumento automatico un acquisto andato a buon fine è un acquisto andato a buon fine, a prescindere dal fatto che il prezzo sia stato manomesso lungo il percorso.

C’è poi una ragione più profonda. Ogni vulnerabilità di logica tende a essere unica, legata al dominio specifico di quell’applicazione. Individuarla richiede di capire cosa l’applicazione dovrebbe fare e quali obiettivi avrebbe un attaccante in quel contesto. È una forma di comprensione che gli strumenti automatici non possiedono, perché nessun catalogo di firme può prevedere le infinite scorciatoie di un processo aziendale particolare. Serve una mente umana che ragioni per ipotesi.

Gli errori ricorrenti

Per quanto ogni falla logica sia diversa, le cause all’origine si ripetono con sorprendente regolarità. Conoscere i casi tipici aiuta a riconoscerli nelle proprie applicazioni.

• Fiducia cieca nei controlli lato client. Molte applicazioni convalidano i dati solo nel browser, dando per scontato che l’utente passi sempre dall’interfaccia ufficiale. Con un proxy che intercetta e modifica le richieste dopo l’invio, quei controlli si aggirano in un istante. Tutto ciò che conta deve essere ricontrollato lato server.
• Manipolazione di prezzo e quantità. Quando il valore di un prodotto o il totale del carrello viaggiano in una richiesta modificabile dall’utente, un attaccante può alterarli. Cambiare il prezzo di un articolo o inserire una quantità negativa per ribaltare il totale sono tra gli abusi più frequenti negli e-commerce.
• Sconti e coupon riutilizzabili. Un codice promozionale pensato per un solo uso, ma non controllato a dovere, può essere applicato più volte oppure sommato ad altri. Lo stesso vale per uno sconto calcolato e poi mai ricontrollato dopo una modifica all’ordine.
• Salto di passaggi nel processo. In una procedura a più stadi, arrivare al pagamento scavalcando un controllo intermedio espone l’azienda a esiti imprevisti. L’applicazione presume che i passaggi avvengano nell’ordine giusto e non gestisce chi li salta.
• Fiducia indefinita dopo un solo controllo. Alcune applicazioni verificano i permessi di un utente all’ingresso, poi si fidano per tutto il resto della sessione. Chi supera quel primo cancello viene trattato come affidabile anche quando compie azioni che meriterebbero un nuovo controllo.
• Race condition. Inviando più richieste nello stesso istante, un attaccante può sfruttare la finestra in cui l’applicazione non ha ancora aggiornato il proprio stato. È così che si riesce a usare due volte lo stesso buono o a spendere due volte il medesimo saldo.

Il caso della falla da 250.000 dollari di Coinbase

Nel 2022 la piattaforma di criptovalute Coinbase ha corretto una vulnerabilità di logica nella sua API di trading avanzato. Il difetto stava in un controllo di validazione mancante. Costruendo a mano una richiesta verso l’API, era possibile vendere una criptovaluta attingendo al saldo di un asset diverso, una mossa che dalla normale interfaccia grafica non sarebbe mai stata permessa.

L’aspetto interessante è che la falla viveva soltanto a livello di API, fuori dalla portata di chi si limitava a usare il sito. Nessun errore tecnico classico, ma una regola di business che l’applicazione dava per garantita e che invece non veniva fatta rispettare sul lato server. Un ricercatore l’ha individuata e segnalata in modo responsabile. Coinbase ha chiuso il problema in poche ore, ha confermato l’assenza di sfruttamenti malevoli e ha riconosciuto al ricercatore una ricompensa da 250.000 dollari, una delle più alte mai assegnate.

Il caso vale più di mille spiegazioni teoriche. Una singola verifica dimenticata, in un punto che nessuno scanner avrebbe segnalato, esponeva una delle piattaforme finanziarie più note al mondo a un rischio enorme.

Come si difende davvero un’azienda

Difendersi dalle vulnerabilità di logica richiede un cambio di prospettiva rispetto alla sola scansione automatica. Servono pratiche che mettano al centro la comprensione del processo e il ragionamento sugli abusi possibili.

• Validare sempre sul lato server.
  Nessun dato che arriva dal browser va considerato affidabile. Prezzi, quantità, identificativi e permessi vanno ricontrollati dal server a ogni passaggio sensibile, senza delegare nulla ai controlli del client.
• Ragionare sugli abusi già in fase di progetto.
  La categoria “Insecure Design” introdotta da OWASP nel 2021 invita a immaginare gli scenari di abuso quando l’applicazione viene disegnata, chiedendosi cosa succede se un utente compie un passaggio al posto di un altro. È un esercizio che blocca molti problemi prima che finiscano nel codice.
• Affidarsi a test manuali condotti da persone.
  Poiché la falla logica nasce dalla comprensione del dominio, solo un analista umano che mette alla prova il flusso applicativo riesce a scovarla. È il cuore di un penetration test mirato sulle applicazioni web.
• Monitorare i comportamenti anomali.
  Totali negativi, coupon usati molte volte, richieste simultanee verso le funzioni critiche e transizioni di stato troppo rapide sono segnali che meritano un controllo. Una sorveglianza attenta intercetta gli abusi anche quando sfuggono ai test.

In conclusione

Le vulnerabilità di logica di business sono tra le più insidiose perché si nascondono dentro funzioni che lavorano esattamente come dovrebbero. Non producono errori, non lasciano tracce riconoscibili e per questo superano indenni le scansioni automatiche, anche quelle assistite dall’intelligenza artificiale. Restano però tra le falle più sfruttate e più costose, perché toccano da vicino i processi su cui un’azienda costruisce il proprio fatturato.

Se ti è piaciuto questo articolo, condividi con noi la tua esperienza.