SQL Injection: Cos'è e Come Funziona

Introduzione

L'SQL Injection (SQLi) è una delle tecniche più comuni e pericolose di attacco per le applicazioni web che utilizzano database SQL.
Questo tipo di attacco sfrutta le vulnerabilità delle query SQL nelle applicazioni per eseguire codice dannoso, con l'obiettivo di manipolare o accedere a informazioni riservate nel database. La conoscenza di questa tecnica è essenziale sia per chi sviluppa software, che per chi gestisce la sicurezza di un sistema informatico.

Cos'è una SQL Injection

La SQL Injection è un tipo di attacco che consente a un malintenzionato di inserire del codice SQL arbitrario nelle query di un’applicazione. Se le query SQL non sono scritte in modo sicuro, l'attaccante può manipolarle per ottenere accesso a informazioni che altrimenti non sarebbero accessibili, come dati degli utenti, informazioni personali, credenziali di accesso e altre risorse sensibili. Gli attacchi SQL Injection possono anche permettere di modificare o eliminare dati, e persino eseguire comandi a livello del sistema operativo, compromettendo seriamente la sicurezza del sistema.

### Come Funziona l'Attacco SQL Injection In un'applicazione vulnerabile, una query SQL potrebbe essere costruita concatenando stringhe, incluse quelle fornite dagli utenti. Per esempio, una query SQL per autenticare un utente potrebbe apparire così:

    
SELECT * FROM utenti WHERE nome_utente = 'utente' AND password = 'password';
    
    

Se l'input dell'utente non viene correttamente filtrato, un malintenzionato potrebbe inserire del codice malevolo direttamente nei campi, come nel seguente esempio:

nome_utente = 'utente' OR '1'='1';

Questo input altererebbe la query SQL, facendola diventare:

SELECT * FROM utenti WHERE nome_utente = 'utente' OR '1'='1';

In questo caso, l'operatore `OR '1'='1'` rende la condizione sempre vera, permettendo all'attaccante di bypassare l'autenticazione ed entrare nel sistema senza avere le credenziali corrette.

Tipi di SQL Injection

1. SQL Injection Basata su Stringa (Union-Based): L'attaccante usa l'operatore `UNION` per combinare risultati di query. Questo permette di ottenere risposte da altre tabelle del database, accedendo così a informazioni riservate.

2. SQL Injection Basata su Errori (Error-Based): Questo metodo sfrutta gli errori generati dal database per ottenere informazioni sulla struttura delle tabelle. Gli errori di SQL forniscono indizi sulle colonne o sui dati nel database.

3. SQL Injection Basata su Tempo (Time-Based): L'attaccante invia query che, se eseguite, rallentano la risposta dell'applicazione (usando comandi come `SLEEP`). Monitorando i tempi di risposta, è possibile dedurre la presenza di una vulnerabilità.

4. Blind SQL Injection (SQL Injection Cieca): Quando il sistema non restituisce errori evidenti, gli attaccanti usano altre tecniche per verificare la presenza di vulnerabilità SQL Injection, estraendo dati lentamente attraverso risposte binarie (sì/no).

Come Proteggersi dalla SQL Injection

La prevenzione della SQL Injection passa attraverso l'adozione di buone pratiche di sviluppo e configurazione di sicurezza. Ecco alcune delle migliori pratiche:
1. Sanitizzazione e Validazione degli Input: L'applicazione deve filtrare e validare tutti i dati inseriti dagli utenti. Ogni parametro passato al database deve essere considerato potenzialmente malevolo fino a prova contraria.

2. Query Parametrizzate: L'uso di query parametrizzate (anche dette *prepared statements*) è una delle difese più efficaci. Questa tecnica consente di separare i dati dagli elementi di comando SQL, impedendo così l'iniezione di codice malevolo.

3.ORM (Object-Relational Mapping): Utilizzare strumenti ORM come Hibernate, che astraggono l'accesso ai dati, può ridurre il rischio di SQL Injection poiché molte operazioni SQL sono precompilate.

4.Principio del Minimo Privilegio: I database dovrebbero essere configurati con permessi minimi per gli account applicativi, in modo che un attacco comprometta solo i dati minimi necessari.

5.Mascheramento degli Errori: Evitare che messaggi di errore completi vengano restituiti agli utenti finali. Gli errori dettagliati devono essere loggati in sistemi sicuri, ma mai visualizzati all'utente.