Lato client
Leggendo la lezione sui i vantaggi portati da AJAX , soprattutto riguardo il server, verrebbe quasi spontaneo pensare ai client come a dei piccoli muletti ausiliari al quale delegare qualunque tipo di operazione.
Questo non dovrebbe accadere, se non nella giusta misura, poichè mentre il server ha del codice compilato o interpretato, comunque non visibile ad occhi indiscreti, il JavaScript o i cookies sul client, non dovrebbero mai contenere informazioni sensibili quali password, numeri di carte di credito, informazioni riservate dalla legge sulla privacy o codici segreti.
Allo stesso tempo bisogna essere molto cauti nell'inviare informazioni anche da parte del server, poichè potrebbe essere semplice replicare una richiesta asincrona da una pagina differente da quella proposta per tentare di leggere dati che si vorrebbero proteggere o non rendere pubblici.
La verifica del client è un'operazione complessa perchè la pagina di provenienza potrebbe non essere veramente quella riscontrata e l'unica soluzione per uno scambio dati asincrono sicuro è l'utilizzo di un'area protetta tramite SSL o altri sistemi dedicati.
Soprattutto nelle aree di amministrazione sarebbe quindi consigliabile non inviare fin da subito tutto il codice di gestione interna ed aggiungerlo dinamicamente solo dopo aver effettuato il login.
Se si ha a che fare con un'area protetta che non prevede un utilizzo degradabile delle operazioni possibili, conoscere tutto il codice addetto a gestire le operazioni potrebbe aumentare in modo più o meno consistente la possibilità di ricevere attacchi esterni.
Questo purtroppo accade molto spesso anche con aree di amministrazione in Flash, quando si lasciano tracce nei file SWF per risalire alle operazioni di modifica dei dati.
Ultimo consiglio è quello di verificare sempre che le funzioni utilizzate lato client siano compatibili con tutti i browser previsti all'interno dell'area di amministrazione. Infatti, qualora una funzione non dovesse essere supportata a pieno ed il browser dovesse tentare lo stesso di utilizzarla si potrebbero aggiornare dati in modo errato o mostrare anomalie all'utente.
Lato server
Un errore purtroppo comune, e non recente, è quello di fare affidamento solo sul codice client.
Questo accade spesso in applicativi Flash e l'unica fortuna di alcuni siti è non contenere dati interessanti per utenti maliziosi. L'errore è presumere che sia solo un certo client con un certo codice ad inoltrare le richieste e che tali richieste rispettino a pieno le regole imposte dallo sviluppatore.
Esistono diversi applicativi che non solo non verificano le autorizzazioni dell'utente ma danno per scontato che se il codice client ha la possibilità di inviare solo un numero, ad esempio un 'id', questo arrivi sicuramente sotto forma di un intero maggiore di zero.
Leggendo il codice client, creandosi una semplice form html, ed inviando una richiesta tipo id=0 or id>0 si potrebbero spolverare decine di database attualmente online, archivi di news, utenti o altro ancora. Il mito da sfatare è quindi che l'uso di AJAX sia pericoloso poichè a renderlo tale può essere solo lo sviluppatore del sistema.
Non esistono controindicazioni specifiche per la sicurezza se non le solite, controllare sempre scrupolosamente che il dato in ingresso, GET o POST che sia, corrisponda al tipo di dato previsto, a prescindere che sia un'operazione da svolgere all'interno di un'area di amministrazione che all'interno di una qualunque pagina destinata agli utenti.
Non è una problematica nuova o complessa, è solo la solita inerente le SQL injections.
Allo stesso tempo su un semplice form di contatti è assolutamente sbagliato fare affidamento ai soli controlli JavaScript. Quante volte è capitato di non poter inviare un messaggio in un'area contatti e disabilitando il JavaScript la stessa area permette di mandare il server in errore?
Superfluo dire che uno sviluppatore esperto potrebbe sfruttare come meglio crede queste possibili via di entrata, come potrebbe sfruttare eventuali valutazioni del codice server o client.
Qualunque sia il prodotto proposto, questo dovrebbe essere prima sicuro senza JavaScript, da aggiungere solo al fine di alleggerire alcune operazioni.
Si potrebbe pensare ad un controsenso, poichè se bisogna verificare tutto, dove stà il vantaggio per il server?
Semplice, invece di ricevere tante richieste quanti sono gli eventuali errori, il client potrebbe aiutare l'utente a non sbagliare richiesta permettendo al server di controllarne ed elaborarne solo una presumibilmente corretta.
Quanto detto è rivolto soprattutto agli sviluppatori Web, poichè in una intranet le possibilità che qualcuno faccia di proposito dei danni saranno sicuramente pochissime se non nulle. Si consiglia comunque una rigorosa cautela, la stessa che si usa per un applicativo senza JavaScript o AJAX.
Considerazioni finali
I punti di maggiore rilievo sono stati trattati con meno superficialità possibile ma purtroppo ogni punto richiederebbe una guida a sé. Abbiamo comunque raccolto la sfida di collegare argomenti differenti ed esempi per tecnologie altrettanto differenti.
Abbiamo illustrato i fondamentali di AJAX ed i metodi per iniziare ad utilizzare questa tecnica o per migliorare quanto già presente. Abbiamo rivolto una particolare attenzione allo sviluppo accessibile, flessibile e veloce, che dovrebbe sempre considerare il contesto in cui si integra, il web 2.0.
