Navigando s’incontrano spesso liste di link, generate in automatico da pagine JSP in funzione dei contenuti d’un DB, che permettono di vedere ed anche modificare i contenuti stessi.

Uno dei più classici link d’una lista è qualcosa del tipo:

oppure del tipo:

Per quanto certamente funzionali allo scopo i due link hanno un, subdolo, difetti: sono pericolosissimi!

Supponendo che i link di cancellazione siano scritti come quello visto sopra, ogni link avrà, dunque, un valore diverso al parametro “idRec”.

Supponiamo ora che l’utente, “sorvolando” uno dei cinque link, s’accorga che il browser lo informa che, cliccandoci, effettuerà la chiamata:

http://miosrv/mia_app/rimuovi.jsp?idRec=1000

Il nostro utente, però, è un tipo intraprendente, e prova a scrivere il link che vede nella barra degli indirizzi, mutandolo in:

http://miosrv/mia_app/rimuovi.jsp?idRec=2123

Sconcertante, vero? Si parla tanto di patching ai sistemi, di buffer overflow, di DoS, di DDoS, d’SQL injection ed invece si scopre che si può svuotare una intera tabella d’un DB, avendo i soli privilegi di poterne cancellare qualcuno e sfruttando una grave mancanza di sicurezza applicativa !!!

Controllare, su ogni pagina che riceva un ID, che appartenga all’utente loggato.

Questa soluzione, tuttavia, aumenta di parecchio la complessità del codice ed appesantisce i tempi esecuzionali.

Criptando i valori degli “idRec” ,inseriti nel codice HTML, inviato al client e decriptandoli alla ricezione,

Questa soluzione porta alla generazione di parametri HTTP parecchio lunghi, se si utilizzano algoritmi di criptazione “sicuri”.

Consiste nel creare delle “bolle” (contesti) di metodi e parametri per attivarli, memorizzate in appositi array nella sessione utente sul server, ed inviando al client link che contengono indici a queste “bolle”.

Questa soluzione utilizza parecchia memoria sul server ma minimizza le informazioni esposte al client. Agevola, inoltre, la gestione degli eventi http.