Cari lettori di Tecnogalaxy, oggi riprenderemo l’argomento sulle tecniche sqlinjection, abbiamo già parlato di questa tecnica in qualche articolo precedente. Questa tecnica di hacking sfrutta alcuni errori nella programmazione di pagine HTML, e consente di inserire ed eseguire codice non previsto all’interno di applicazioni web che interrogano un database.

La SQL injection è particolarmente pericolosa perchè non richiede l’uso di strumenti particolari, serve solo un PC e un qualsiasi browser tra quelli comunemente utilizzati per la navigazione sul web.

Ogni sito web che si interfaccia con un database è potenzialmente vulnerabile ad un attacco SQL injection.

Ovviamente una programmazione poca attenta alla sicurezza può accrescere in modo significativo le vulnerabilità mettendo in serio pericolo le logiche di elaborazione che costituiscono le transazioni SQL.

Come funziona

Per capire come funziona questa tecnica di attacco, bisogna prima capire come funziona la comunicazione tra un server che eroga servizi, (dove è presente un database), ed un client che effettua le interrogazioni usufruendo dei servizi.

Facciamo un esempio utilizzando il meccanismo di interrogazione e dialogo tra client, server e DB, simulando l’accesso di utente al suo profilo personale (la classica login).

Il visitatore accede alla pagina di login che risiede su di un server (sito web).

Il server web elabora la pagina in locale e produce una pagina in HTML che viene inviata al browser del client, che visualizzerà il risultato sullo schermo del visitatore.

L’utente inserirà le proprie credenziali sul form di login; che invierà i dati al server web che tramite l’esecuzione di uno script PHP interrogherà il proprio database (MySQL).

Il database solo in caso di corrispondenza delle credenziali con quelle salvate nel db, darà una risposta al server con i dati richiesti.

Di conseguenza il server web provvederà in locale ad impaginare la risposta e ad inviarli al browser del client. L’utente visualizzerà una pagina con le informazioni relative al servizio richiesto. (Ad esempio i propri dati anagrafici).

A livello di programmazione è importantissimo adottare delle misure minime di protezione al fine di evitare lo sfruttamento di ogni eventuale vulnerabilità.

La parte più delicata è quella di mettere in sicurezza il codice utilizzato per la gestione di moduli di autenticazione e pagine di ricerca, (in genere sono implementati prevedendo un’archiviazione e un’interazione con un database), queste sono le potenziali porte di accesso.

Un malintenzionato esperto di sintassi SQL, può inviare istruzioni attraverso le pagine del sito che prevedano un dialogo con il DB. Tale obiettivo sarà quello di ottenere un accesso non autorizzato all’applicazione stessa, recuperando le informazioni come dati sensibili e modificarli o eliminarli.

Fasi preliminari per un attacco

Come tutti tipi di attacchi la prima fase utilizzata da un attaccante sarà quella di capire quando e come l’applicazione interagisce con un server DB per accedere ad alcuni dati.

Se l’application web che vogliamo testare ha queste funzionalità significa che comunica con un database:

  1. moduli web: la classica pagina di login.
  2. motori di ricerca: la stringa per la ricerca inviata dall’utente può essere utilizzata in una query SQL che estrae da un database i record rispondenti alla richiesta.
  3. siti di commercio elettronico: le informazioni sui prodotti e le loro caratteristiche sono probabilmente archiviate in un database.

Il passo successivo sarà quello di interpretare i messaggi di errore che un applicativo restituisce in caso di inserimenti anomali. Nel caso gli sviluppatori abbiamo bloccato qualsiasi tipo di messaggio (feedback), sarà comunque possibile provare a capire il comportamento del server DB, utilizzando delle tecniche come ad esempio lo sniffing per l’intercettazione del traffico di rete.

Anatomia di un attacco SQL Injection

Questo tipo di attacco prevede l’inserimento di termini appositi nei campi presenti in un modulo web, in questo modo sarà possibile inviare al database comandi inconsueti e imprevisti sfruttando l’applicazione stessa.

Passiamo nel dettaglio facendo un esempio concreto, eseguendo una query che interroga il database per recuperare le informazioni relative al nominativo di un utente. (Tramite il metodo POST di un form HTML )

Ci tengo a precisare che il problema è del tutto indipendente dal tipo di piattaforma utilizzata.

Il test che segue si è stato fatto con il tool OSWAP dedicata al testing SQL injection, con la seguente query mysql:

Se non è presente alcuna forma di validazione dell’input, (controlli all’interno del codice di programmazione),  un potenziale attaccante potrebbe provare ad inserire le seguenti username e password per cercare di mandare in errore il database:

$_POST[“nominativo”]= 1 ‘OR’ 1 ‘=’ 1
$_POST[“password”]= 1 ‘OR’ 1 ‘=’ 1

Questa combinazione con l’uso delle virgolette con l’operatore logico “OR” genera il seguente comando SQL modificato ed inviato al DB:

Questa query può causare la restituzione del primo o di più valori della tabella utenti, la clausola WHERE viene ora soddisfatta da ogni voce della tabella utenti, perchè la parte introdotta dall’istruzione logica OR è sempre verificata.

Possiamo anche includendo dei delimitatori di commenti, come ad esempio (/*…*/), così da provare a far ignorare addirittura alcune parti delle query, come ad esempio quella relativa al campo password.

Con questa tecnica è possibile recuperare le credenziali amministrative di un database, di solito il primo utente della lista è proprio l’account admin.

Una volta trovati i punti di accesso ed individuate le vulnerabilità, il malintenzionato può proseguire con attacchi più potenti di iniezione SQL, come la manipolazione degli archivi digitali e/o l’esecuzione di routine personalizzate.

Come difendersi?

Per prevenire questo tipo di attacco sulle applicazioni che interagiscono con un database, in fase di implementazione del progetto, stabilire nel dettaglio la parte che prevede un controllo di tutte le potenziali porte di accesso all’archivio di gestione dei dati, come ad esempio i form, le pagine di ricerca e qualsiasi altro modulo che preveda una interrogazione SQL.

Il controllo con la relativa validazione degli input e le query parametrizzate tramite template ed una adeguata gestione dei report sugli errori,  possono rappresentare delle buone pratiche di programmazione utili allo scopo.

Di seguito alcuni accorgimenti da implementare:

  1. Analizzare nel dettaglio l’utilizzo degli elementi di codice SQL potenzialmente a rischio, come ad esempio le virgolette singole e le parentesi, (potrebbero essere integrati con opportuni caratteri di controllo e sfruttati per usi non autorizzati, come spiegato prima.)
  2. usare l’estensione MySQLi;
  3. disattivare sul sito la visibilità delle pagine degli errori. Tali informazioni si rivelano preziose per chi sta attaccando, potrebbe risalire all’identità e alla struttura dei server DB interagenti con l’applicazione bersaglio.

Ovviamente restano sempre valide le buone regole come quella di aggiornare i tools in uso, con le ultime release e patch che i fornitori legittimi mettono periodicamente a disposizione.

Adottare una corretta politica (parte molto importante), per la gestione dei privilegi SQL per le utenze che lo utilizzano.

Come sempre fatene buon uso facendo dei test su vostri device / computer , farli su device/computer non vostri è illegale.

Al prossimo articolo!

N.B.: Non mi assumo nessuna responsabilità dell’uso che farete della guida, in quanto stilata per uso didattico e formativo.

Giorgio Perego

IT Manager

Ti è stato di aiuto questo articolo? Aiuta questo sito a mantenere le varie spese con una donazione a piacere cliccando su questo link. Grazie!

Seguici anche su Telegram cliccando su questo link per rimanere sempre aggiornato sugli ultimi articoli e le novità riguardanti il sito.

Se vuoi fare domande o parlare di tecnologia puoi entrare nel nostro gruppo Telegram cliccando su questo link.

© Tecnogalaxy.it - Vietato riprodurre il contenuto di questo articolo.