Ormai la maggior parte dei siti internet contemporanei utilizza un database di riferimento per il salvataggio ed il reperimento dei dati. Diventa quindi di vitale importanza la fase di interrogazione verso questo sistema.
Un tipico attacco verso un database è molte volte viene portato tramite una tecnica detta “SQL Injection” in cui si cerca di modificare una query legittima per reperire dati altrimenti inaccessibili o per ottenere privilegi superiori a quelli consentiti.
Di seguito viene riportato un esempio di questo attacco:
Form di autenticazione:
<form method=’POST’ action=’login.php’>
Username: <input type=’text’ name=’username’ /> <br />
Password: <input type=’password’ name=’password’ /> <br />
<input type=’submit’ value=’login’>
</form>
Script login.php:
$username=$_POST['username'];
$password=$_POST['password'];
$sql = ‘SELECT * FROM utenti WHERE username=’ . $username . ‘ AND password=’ . $password . ‘ ‘;
// connessione al database e valutazione del risultato
if (count($result)> 0){
// Login avvenuto con successo
}
Cosa accadrebbe se un utente nel campo nome utente inserisse:
$username OR 1=1
Siccome il costrutto OR 1=1 da sempre esito positivo, l’utente in questione anche se non è a conoscenza della password e del nome utente può accedere tranquillamente all’area riservata.
Per arginare questo tipo di “Injection” è sufficiente controllare il formato delle variabili immesse dall’utente. Nell’esempio precedente sarebbe necessario utilizzare una funzione *_escape_string() per eliminare il problema, ecco il dettaglio (caso di DBMS Mysql):
$username=mysql_escape_string($_POST['username']);
$password=md5(mysql_escape_string($_POST['password']));
Un altro modo per attaccare sistemi web e database correlati è quello di inondarlo di registrazioni, in modo tale da renderlo più pesante e quindi meno fruibile.
Ovviamente questo tipo di attacco si sposa con siti web che forniscono agli utenti la possibilità di registrarsi liberamente.
Esistono in questi casi script generati ad-hoc in grado di eseguire un numero considerevole di registrazioni in poco tempo, dato che sono in grado di compilare le form di attivazione in modo automatico.
Un metodo per difendersi da questo floodingdi richieste sta nel test CAPTCHA . Tale test, il cui significato è Completely Automated Public Turing test to tell Computers and Human Apart non permette la registrazione automatica perché costringe l’utente in fase di inserimento dati a estrapolare una frase seminascosta in un immagine, eccone un esempio:
La bontà del test sta nella capacità di nascondere le lettere ad una “macchina” ma non ad una persona. Il metodo in questione non è infallibile, la sua integrità viene avvalorata dalla accuratezza con cui le immagini vengono generate.
Maggiori dettagli si possono trovare al sito ufficiale http://www.captcha.net/











Salve, quindi l’SQL Injection può avvenire solo tramite codice scritto “male” o in altri modi?
Se per codice scritto male si intende non controllare che tipo di dati può inserire un utente direi proprio di sì.