A06:2025 Insecure Design: la sicurezza si progetta, non si aggiunge
STRIDE, abuse case, security requirement nelle user story, difesa in profondità
Questa voce è diversa da tutte le altre viste finora. OWASP traccia una linea netta: un design insicuro non si può correggere con un'implementazione perfetta. I controlli necessari non sono mai stati previsti, quindi non c'è codice, per quanto ben scritto, che possa colmare quel vuoto.
È la differenza tra una casa costruita senza uscite di sicurezza e una con l'uscita antincendio bloccata da uno scatolone. Nel secondo caso basta spostare lo scatolone: un fix rapido. Nel primo, l'uscita semplicemente non esiste: serve rifare parte della struttura, non pulire meglio quella che c'è.
1. STRIDE: una checklist per chiedersi «cosa può andare storto»
Il threat modeling, l'analisi sistematica delle minacce prima di scrivere codice, è il cuore di questa voce. Una delle metodologie più diffuse è STRIDE, sviluppata da Microsoft (Loren Kohnfelder e Praerit Garg) per classificare le minacce in sei categorie.
Spoofing: qualcuno finge di essere un altro utente.
Tampering: qualcuno modifica dati senza permesso.
Repudiation: qualcuno nega di aver fatto un'azione, e non puoi provarlo.
Information disclosure: dati sensibili esposti a chi non dovrebbe vederli.
Denial of service: il sistema diventa inutilizzabile per gli utenti legittimi.
Elevation of privilege: qualcuno ottiene permessi superiori a quelli previsti.
Applicare STRIDE significa, per ogni funzionalità critica, chiedersi sistematicamente: «in che modo qualcuno potrebbe usarla per uno di questi sei scopi?», prima di scrivere il codice, non dopo.
Microsoft affianca a ogni categoria il controllo di sicurezza che serve a contrastarla: l'autenticazione per lo spoofing, l'integrità per il tampering, il non ripudio per la repudiation, la riservatezza per l'information disclosure, la disponibilità per il denial of service e l'autorizzazione per l'elevation of privilege. Ogni minaccia individuata indica così da quale controllo partire nel progetto.
2. Use case e abuse case: progettare pensando a chi vuole barare
La raccomandazione ufficiale OWASP è specifica: compila use case e misuse case per ogni livello dell'applicazione. Un caso d'uso descrive cosa un utente legittimo dovrebbe poter fare; un abuse case descrive come quella stessa funzionalità potrebbe essere piegata a uno scopo malevolo.
Lo scenario ufficiale più concreto: una catena di cinema permette prenotazioni di gruppo con sconto, fino a un massimo di quindici persone prima di richiedere un acconto. Un attaccante può analizzare quel flusso e testare se riesce a prenotare seicento posti in tutte le sale contemporaneamente con poche richieste: una perdita economica enorme, senza aver mai «rotto» nulla tecnicamente. Ha solo usato la funzionalità come progettata, portandola all'estremo che nessuno aveva previsto.
3. Portare la sicurezza dentro le user story
Un'altra raccomandazione ufficiale, spesso trascurata: integrare linguaggio e controlli di sicurezza direttamente nelle user story, non come documento a parte che nessuno legge, ma come parte dei criteri di accettazione della funzionalità stessa.
Come utente registrato
voglio poter reimpostare la password
cosi' da recuperare l'accesso al mio account
Criteri di accettazione:
- Il link di reset scade dopo 1 ora
- Il token e' utilizzabile una sola volta
- La risposta e' identica sia che l'email esista sia che non esista
(niente enumerazione degli account registrati)OWASP raccomanda anche di determinare esplicitamente, in fase di scrittura della user story, il flusso corretto e gli stati di fallimento, assicurandosi che siano compresi e concordati da chi è responsabile e da chi è impattato.
4. Un design da eliminare, non da correggere
Lo scenario ufficiale più netto: un flusso di recupero credenziali basato su «domande e risposte» (il classico «qual è il nome del tuo primo animale?») è esplicitamente vietato da NIST 800-63b, OWASP ASVS e dalla stessa OWASP Top 10. Il motivo: quelle risposte non possono essere considerate prova d'identità, perché più di una persona può conoscerle. OWASP è diretto: questa funzionalità va rimossa e sostituita con un design più sicuro, non corretta.
Per la difesa in profondità, OWASP raccomanda di segregare i livelli, sistema, rete, tenant, in base all'esposizione e al bisogno di protezione: se un livello viene compromesso, gli altri restano comunque protetti, invece di cadere tutti insieme.
In sintesi
Il filo conduttore di questa voce è un cambio di tempo verbale: non «come correggo questa vulnerabilità», ma «come la previeni prima che il codice esista». È l'unica voce della Top 10 che si gioca quasi interamente prima di scrivere una singola riga.
Commenti (0)
Registrati per commentare, fare domande e proporre l'argomento della prossima pillola (oppure accedi se hai già un account).
Nessun commento. Sii il primo a scrivere qualcosa.