A10:2025 Mishandling of Exceptional Conditions

Contesto.

La gestione impropria delle condizioni eccezionali è una nuova categoria per il 2025. Questa categoria contiene 24 CWE e si concentra sulla gestione impropria degli errori, errori logici, failing open e altri scenari correlati derivanti da condizioni anomale che i sistemi possono incontrare. Questa categoria include alcuni CWE precedentemente associati a scarsa qualità del codice. Per noi era troppo generico; a nostro avviso, questa categoria più specifica fornisce indicazioni migliori.

CWE notevoli inclusi in questa categoria: CWE-209 Generation of Error Message Containing Sensitive Information, CWE-234 Failure to Handle Missing Parameter, CWE-274 Improper Handling of Insufficient Privileges, CWE-476 NULL Pointer Dereference, e CWE-636 Not Failing Securely ('Failing Open').

Tabella dei punteggi.

CWE Mappati	Tasso di Incidenza Massimo	Tasso di Incidenza Medio	Copertura Massima	Copertura Media	Exploit Ponderato Medio	Impatto Ponderato Medio	Occorrenze Totali	CVE Totali
24	20,67%	2,95%	100,00%	37,95%	7,11	3,81	769.581	3.416

Descrizione.

La gestione impropria delle condizioni eccezionali nel software si verifica quando i programmi non riescono a prevenire, rilevare e rispondere a situazioni insolite e imprevedibili, il che porta a crash, comportamenti imprevisti e talvolta vulnerabilità. Questo può coinvolgere uno o più dei seguenti 3 fallimenti: l'applicazione non previene una situazione insolita, non la identifica mentre si sta verificando e/o risponde in modo inadeguato o non risponde affatto alla situazione in seguito.

Le condizioni eccezionali possono essere causate da validazione dell'input mancante, scarsa o incompleta, o gestione degli errori tardiva ad alto livello invece che nelle funzioni dove si verificano, o stati ambientali imprevisti come problemi di memoria, privilegi o rete, gestione incoerente delle eccezioni, o eccezioni non gestite del tutto, che permettono al sistema di cadere in uno stato sconosciuto e imprevedibile. Ogni volta che un'applicazione non è sicura della sua prossima istruzione, una condizione eccezionale è stata gestita in modo improprio. Errori ed eccezioni difficili da trovare possono minacciare la sicurezza dell'intera applicazione per molto tempo.

Molte diverse vulnerabilità di sicurezza possono verificarsi quando gestiamo male le condizioni eccezionali, come bug logici, overflow, race condition, transazioni fraudolente, o problemi con memoria, stato, risorse, timing, autenticazione e autorizzazione. Questi tipi di vulnerabilità possono influenzare negativamente la riservatezza, la disponibilità e/o l'integrità di un sistema o dei suoi dati. Gli attaccanti manipolano la gestione degli errori difettosa di un'applicazione per colpire questa vulnerabilità.

Come prevenire.

Per gestire correttamente una condizione eccezionale dobbiamo pianificare tali situazioni (aspettarsi il peggio). Dobbiamo "catturare" ogni possibile errore di sistema direttamente nel punto in cui si verifica e poi gestirlo (il che significa fare qualcosa di significativo per risolvere il problema e assicurarci di riprenderci dalla questione). Come parte della gestione, dovremmo includere la generazione di un errore (per informare l'utente in modo comprensibile), la registrazione dell'evento, nonché l'emissione di un alert se riteniamo che sia giustificato. Dovremmo anche avere un gestore globale delle eccezioni nel caso in cui ci sia qualcosa che abbiamo mancato. Idealmente, avremmo anche strumenti o funzionalità di monitoraggio e/o osservabilità che vigilano su errori ripetuti o pattern che indicano un attacco in corso, in grado di emettere una risposta, una difesa o un blocco di qualche tipo. Questo può aiutarci a bloccare e rispondere a script e bot che si concentrano sulle nostre debolezze nella gestione degli errori.

Catturare e gestire le condizioni eccezionali garantisce che l'infrastruttura sottostante dei nostri programmi non sia lasciata a gestire situazioni imprevedibili. Se siamo nel mezzo di una transazione di qualsiasi tipo, è estremamente importante eseguire il rollback di ogni parte della transazione e ricominciare (noto anche come failing closed). Tentare di recuperare una transazione a metà è spesso il punto in cui creiamo errori irrecuperabili.

Quando possibile, aggiungere rate limiting, quote di risorse, throttling e altri limiti ovunque sia possibile, per prevenire le condizioni eccezionali in primo luogo. Nulla nell'informatica dovrebbe essere illimitato, poiché questo porta a mancanza di resilienza applicativa, denial of service, attacchi a forza bruta riusciti e bollette cloud straordinarie. Considerare se errori ripetuti identici, al di sopra di un certo tasso, debbano essere emessi solo come statistiche che mostrano con quale frequenza si sono verificati e in quale arco temporale. Queste informazioni dovrebbero essere aggiunte al messaggio originale in modo da non interferire con il logging e il monitoraggio automatizzati, vedere A09:2025 Security Logging & Alerting Failures.

Oltre a questo, vorremmo includere una validazione rigorosa dell'input (con sanificazione o escaping per caratteri potenzialmente pericolosi che dobbiamo accettare), e gestione degli errori centralizzata, logging, monitoraggio e alerting, e un gestore globale delle eccezioni. Un'applicazione non dovrebbe avere più funzioni per la gestione delle condizioni eccezionali, dovrebbe essere eseguita in un unico posto, allo stesso modo ogni volta. Dovremmo anche creare requisiti di sicurezza del progetto per tutti i consigli in questa sezione, eseguire attività di threat modeling e/o revisione del design sicuro nella fase di progettazione dei nostri progetti, eseguire code review o analisi statica, nonché eseguire test di stress, prestazioni e penetration testing del sistema finale.

Se possibile, l'intera organizzazione dovrebbe gestire le condizioni eccezionali allo stesso modo, poiché rende più facile rivedere e verificare il codice per errori in questo importante controllo di sicurezza.

Scenari di attacco di esempio.

Scenario #1: L'esaurimento delle risorse dovuto alla gestione impropria delle condizioni eccezionali (Denial of Service) potrebbe essere causato se l'applicazione cattura le eccezioni quando i file vengono caricati, ma non rilascia correttamente le risorse dopo. Ogni nuova eccezione lascia risorse bloccate o altrimenti non disponibili, finché tutte le risorse non sono esaurite.

Scenario #2: L'esposizione di dati sensibili tramite la gestione impropria degli errori del database che rivela l'errore di sistema completo all'utente. L'attaccante continua a forzare errori al fine di utilizzare le informazioni di sistema sensibili per creare un attacco SQL injection migliore. I dati sensibili nei messaggi di errore all'utente sono ricognizione.

Scenario #3: La corruzione dello stato nelle transazioni finanziarie potrebbe essere causata da un attaccante che interrompe una transazione multi-step tramite interruzioni di rete. Immaginate che l'ordine della transazione fosse: addebitare l'account utente, accreditare l'account di destinazione, registrare la transazione. Se il sistema non esegue correttamente il rollback dell'intera transazione (failing closed) quando si verifica un errore a metà, l'attaccante potrebbe potenzialmente prosciugare l'account dell'utente, o possibilmente una race condition che consente all'attaccante di inviare denaro alla destinazione più volte.

Riferimenti.

OWASP MASVS‑RESILIENCE