SQL-Injection

L’impatto può variare a seconda di molteplici condizioni che variano dalla presenza di molteplici databases ai permessi dell’utente alla configurazione del sistema. 

Se correttamente sfruttata, una vulnerabilità di questo tipo potrebbe portare, per esempio, a:

1. Accesso completo ai dati del databases (ivi compresi dati personali degli utenti, credenziali d’autenticazione, etc)
2. Accesso al sistema operativo tramite Reverse Shell

Esistono tre categorie di SQL Injection: 

1. In Band SQLi: è la forma più comune, in cui l’attaccante sfrutta un parametro per interagire con il database e visualizzare direttamente la risposta sul sito web. Ci sono due sotto-categorie:
   • • Error-based SQLi: l’attaccante cerca deliberatamente di provocare degli errori per acquisire informazioni – come i nomi dei databases e delle tabelle – tramite gli errori generati.
     • Union-based SQLi: l’attaccante sfrutta l’operatore UNION di SQL per unire più istruzioni ed ottenere molte informazioni con un unica richiesta HTTP.
2. Blind SQLi: questa tipologia si basa osservando i comportamenti del server e delle risposte della pagina. Infatti, questa tecnica viene chiamata “blind” appunto perchè l’attaccante non riesce a visualizzare le stringhe dei possibili errori SQL prodotti dal database. L’attacco si basa esclusivamente sul comportamento della risposta del server e, quindi, richiedono un tempo particolarmente prolungato per trovare efficacia. Queste tipologie si possono dividere in due metodologie:
   • • Boolean: l’attaccante invia un query SQL chiedendo all’applicazione di restituire un risultato; questo varia a seconda della query che potrebbe essere sia vera che falsa e, basandosi sul risultato del database, le informazioni visibili a schermo potrebbero cambiare. Da questo comportamento, l’attaccante, può capire se il messaggio ha generato un risultato vero o falso.
     • Time-based: l’attaccante invia al database una query SQL di “sleep”, nello specifico, chiede al database di attendere per un periodo di tempo prima di eseguire la risposta. Quindi è possibile capire se esiste una possibile vulnerabilità SQL basandosi sul tempo della risposta del server confrontando il tempo inserito dall’attaccante nella query (solitamente in secondi) e quello di risposta della pagina.
3. Out of band SQL (OOB): è la tecnica meno frequente d’attacco in quanto richiede delle precondizioni molto particolari per poter essere sfruttata. Nella fattispecie, questa tecnica d’attacco è possibile esclusivamente quando l’attaccante non utilizza lo stesso canale per ricevere le informazioni dal payload utilizzato o quando il server è instabile/lento. Sostanzialmente, questa vulnerabilità si palesa quando il server del database ha la possibilità di effettuare richieste DNS o HTTP per comunicare i dati al cracker.

1. Bypass dell’autenticazione attraverso il metodo “Boolean”. Come si può vedere nella gif sotto riportata, inserendo la stringa "' OR 1=1 -- '"  la query al database viene costretta a restituire un valore TRUE dal payload OR 1=1. Eventuali prosecuzioni della query al database vengono preventivamente stroncate tramite l’inserimento del commento “–“. Così facendo, qualsiasi sia il valore immesso nella credenziale utente, il valore booleano della query SQL restituirà sempre TRUE e l’utente potrà loggarsi al posto dell’utente bypassando, di conseguenza, l’intero processo d’autenticazione.
2. Estrazione di dati attraverso la metodologia “Union-based”: questa tipologia di iniezione viene utilizzata per accedere indebitamente ai dati conservati nel database. Nella rappresentazione sottostante, sono state richieste delle informazioni preliminari dall’information_schema per poter, nel caso, visualizzare ulteriori dati.   

Ci sono due modi principali, entrambi necessari e di per sé non sufficienti, per proteggere un database da input dannosi: entrambe le metodologie devono essere necessariamente applicate in sequenza.

1. 1. processo di sanificazione dell’input: si costituisce di varie istruzioni volte a rimuovere caratteri potenzialmente dannosi come, ad esempio, apici, virgolette alte, virgolette basse, trattini, slash, backslash, asterischi, dollari, etc. Solitamente, si tende a manipolare tali caratteri aggiungendo caratteri di escape o rimuovendoli direttamente ma ciò dipende, ovviamente, dalla tipologia di input che ci si dovrebbe aspettare.
      
      
      ATTENZIONE: i caratteri speciali possono essere anche soggetti a codifiche – anche plurime.
      
      
      
   2. Processo di validazione o di convalida dell’input sanificato. La domanda che bisogna porsi è: è coerente con la tipologia attesa? Un esempio, forse, può spiegare meglio questo step: se aspetto in input il CAP di una città, questo potrà essere composto esclusivamente da caratteri numerici.