AJAX: basi di sicurezza

Qualche giorno fa un bell'articolo pubblicato su SecurityFocus, di cui forniremo abbiamo fornito una traduzione fra alcuni giorni sul nostro canale dedicato alla sicurezza informatica, ha riproposto il tema della sicurezza nella progettazione di applicazioni Web, in particolare di applicazioni scritte in AJAX.

Dopo aver spiegato cosa è AJAX, gli autori passano subito al tema dell'articolo: "AJAX non introduce intrinsecamente nuove vulnerabilità  nel mondo delle applicazioni Web" e le applicazioni scritte con questa tecnologia "hanno di fronte le stesse problematiche delle applicazioni Web classiche". Ma "non sono state messe a punto buone pratiche comuni" che possono condurre a brutte sorprese. AJAX non è insicuro di per sé, ma il cambiamento di modello di programmazione potrebbe favorire delle pessime, dal punto di vista della sicurezza, abitudini. E allora ecco alcune "zone" su cui concentrare l'attenzione per quanto riguarda la sicurezza.

Controlli di sicurezza lato client: poiché il ruolo del client, nelle applicazioni AJAX, è molto più preponderante rispetto ad un modello classico, qualcuno potrebbe essere portato a spostare su quel lato della comunicazione i controlli di sicurezza. Male. Dal lato del client è molto più facile forzare un'applicazione: "i controlli di sicurezza devono essere sempre implementati lato server o rinforzati sul server".

Aumento della superficie di attacco: "AJAX aumenta inevitabilmente la complessità  del sistema" poiché, per favorire dinamicità  e reattività , aumenta e moltiplica le comunicazioni con il server. Ogni nuova funzione, e ogni nuova interazione, può essere un punto di attacco al sistema: "è come dover programmare la sicurezza di una casa con dieci porte in confronto con una con una porta sola".

Meno "spazio" fra utenti e servizi: con l'uso di Ajax c'è il rischio di scardinare il modello three-tier poiché il ruolo del middleware, ossia dell'applicazione che gestisce il controllo e la lettura dei dati, viene sempre meno. Utilizzando JavaScript e XML e un modello SOA l'untente finale viene messo direttamente di fronte ai web service, ossia ai dati.

Nuove possibilità  di Cross Site Scripting: è una delle cose che abbiamo discusso già  in un altro post: una cattiva programmazione, unita ad un hack del modello di protezione del browser e facilitata dall'interazione asincrona di AJAX (che rende invisibile all'utente lo scambio di dati con il server) è una combinazione con cui i piccoli cracker vanno a nozze.