Nell’interazione tra i siti web e i database di back-end, l’utente malizioso può trovare spazi dove mettere in pratica tecniche per effettuare remotamente query SQL sul database e leggere dati non pubblici o non destinati alla sua utenza. Questo è il problema dell’SQL Injection.Gli ultimi studi si stanno dedicando ad caso ancora più grave: verificare la possibilità di iniettare nel sistema, con queste stesse tecniche, dei trigger che eseguano del codice arbitrario. Data una form sul web per l’autentificazione dell’utente, supponiamo che la chiamata SQL contenuta nella pagina .ASP che gestisce la procedura per vedere se nel database l’utente esiste ed è autorizzato siaSELECT dati_segreti FROM USER_TABLE where user = ‘username’ and pass = ‘password’;se, a prescindere dallo username, un utente scrivesse come password “’ or 1=1 -- “, (attenzione all’apice) in esecuzione il db vedrebbe il seguente comando SQLSELECT dati_segreti FROM USER_TABLE where user = ‘username’ and pass = ‘’ or 1=1 --’;La condizione 1=1 sulla password sarebbe sempre vera. (Il “--“ serve a far passare come commenti tutti i messaggi di servizio dal db al parser ASP.) Chi avesse inserito una simile password avrebbe accesso a tutti i dati dell’utente “username” senza conoscerne la password.Questo è solo un esempio base: con chiamate simili, ma molto più complesse, si possono fare operazioni di ogni tipo sul database, modifiche, cancellazioni, copie.L’SQL Injection non è eliminabile tramite script di gestione delle stringhe in esecuzione sul browser, che sono del tutto inutili se si fa una copia off-line della pagina che propone l’autentificazione. Non è neanche eliminabile nemmeno a livello database: il db non può decidere se la condizione 1=1 è voluta dall’utente o meno, si pensi tralaltro alle fasi di debug delle applicazioni web in cui i programmatori fanno largo uso di condizioni sempre vere o sempre false.Non resta che eliminare tutti i caratteri che possono essere usati per veicolare insidie tramite la gestione delle stringhe sugli script (es. ASP, PHP, JSP) che stanno tra il webserver ed il database. Ulteriori contromisure si possono adottare lavorando sui permessi (grant) concessi agli utenti del database in modo da eliminare per quanto possibile le possibilità di modifica e cancellazione all’utente “webserver”.Questo tipo di problema è quindi una vulnerabilità che non dipende dall’architettura, ma essenzialmente dagli script che stanno tra web server e database. Tentare di fermare l’insidia tramite un firewall se non è impossibile è sicuramente inadeguato. Per la natura stessa dei web site, che sono sviluppati su misura per il cliente, nessuno che faccia uso di un database di back-end può dirsi tutelato dai bollettini di sicurezza dei fornitori. Ogni soggetto che voglia prevenire danni al proprio sistema informatico, deve fare del code audit sul codice che gestisce l’interazione tra applicativo e database: tramite sistemi più complessi di quello visto sopra è possibile comandare praticamente a piacimento il database, proprio a causa della cattiva programmazione degli script – si pensi a questo proposito ai problemi causati dal PHP Nuke.Risolvere i problemi di questo tipo è quanto mai attuale e per la continua originalità dei sistemi da analizzare che non lasciano possibilità alla serializzazione dei controlli e per la centralità assunta dai sistemi di memorizzazione, come i database, in tutti contesti informatici.Analizzare la suscettibilità dei server all’SQL Injection pone il lavoro dell’informatico su un piano dove intuito e capacità di adattamento alle situazioni sono requisiti indispensabili.