Non parlo di hack nel senso più comune del termine, ma il problema riguarda certamente l'Application Security.
Il fatto: In questi giorni ho "ricevuto" circa 60000 trackback su alcuni miei post del blog.
Il risultato: I post diventano non caricabili da browser perché la pagina è troppo lunga e il download durerebbe probabilmente ore. Apparentemente durante questi lunghi caricamenti la web application va in crash e IIS giustamente ricicla.
Tentativo di mitigazione da parte dell'utente: È inutile tentare di cancellare 10 post alla volta (questo è il massimo consentito nella pagina amministrativa di subtext) visti anche i tempi titanici di questa operazione. La sensazione è che vengano mandate 10 delete invece di una delete con una where sui 10 id, o meglio una semplice update della colonna delete per poi fare la vera cancellazione in un batch giornaliero.
Come avrebbe potuto aiutare l'applicazione di SDL in questo specifico caso? Tantissimo infatti per questo problema ogni singolo punto di SDL avrebbe aiutato a mitigare il problema. SDL si basa su quattro principi fondamentali:
- Secure by Design. Un attacco sul trackback può portare a DoS (Denial Of Service). Le conseguenze dell'attacco sono tali da dover prevedere una mitigazione adeguata. Non è possibile ad esempio moderare i trackback.
- Secure by Default. I trackback sono abilitati di default senza moderazione e senza filtro spam (che attualmente è bucato). Anche i commenti sono abilitati di default senza captcha ma è presente un filtro spam che sta facendo il suo lavoro.
- Secure in Deployment. Non posso dirlo con certezza, ma sul mio blog che ha subito un upgrade da dottext ho visto impostazioni differenti sia rispetto ad una installazione nuova che ho fatto una mia macchina, sia rispetto alle vecchie impostazioni che avevo su dottext. Questo potrebbe essere un classico problema di problematiche legate al tipo di deployment. Non conoscendo i dettagli dell'installazione non posso riportare altro se non quello che vedo.
- Communications. Prontezza e reazione alla vulnerabilità. Il problema lo aveva già avuto Lorenzo ma non è stato fatto nulla. In casi estremi una contromisura può essere semplicemente quella di fornire una query che disabiliti i trackback su tutti i blog, avvisando ovviamente gli utenti del potenziale pericolo.
SDL non fornisce solo dei punti in cui architetto, sviluppatore, tester, e resto del team sono coinvolti nel strutturare l'applicazione in modo sicuro. SDL indica anche una via pragmatica che usa come strumento principale il threat modeling.
Il threat modeling è un modo per far crescere l'applicazione evitando principalmente problemi di design. Senza dilungarmi su concetti di cui ho già parlato tante volte, il nuovo modello di threat modeling prevede una semplificazione sulla quantificazione delle minacce dal vecchio DREAD in Probabilità e Impatto. Il rischio è il prodotto di questi due fattori. Altro concetto importante del nuovo modello è la nuova categorizzazione delle minacce da STRIDE a Confidentiality, Integrity e Availability.
Per quanto concerne questo caso specifico, SubText è soggetto a problemi di Availability in quanto alcuni post non possono essere più caricati. Il rischio associato è passato da mediamente probabile ad altamente probabile da quando si sono verificati dei casi (vedi Lorenzo) ed ha un Impatto massimo (tre su una scala 1-3).
SDL quindi indica precisamente quali siano i problemi e fornisce anche una valutazione oggettiva di rischio da cui il team avrebbe dovuto prendere delle decisioni secondo la scala dei valori assegnati. SDL non prescrive di fixare tutti i problemi ma lascia la discrezione al team di sviluppo che può valutare proprio grazie alla graduatoria oggettiva del rischio a cui sta andando incontro.
Il threat modeling in realtà può fare molto di più di questo. Il nuovo modello permette l'analisi dal punto di vista del defender che ha una conoscenza profonda di tutta l'architettura e dei potenziali punti di attacco. Il defender è in grado di fare molto di più rispetto ai problemi che ho elencato che sono solo la punta dell'iceberg.