Phenquestions
La vulnerabilità al troncamento SQL di solito esiste nei database MySQL. Questa vulnerabilità è stata descritta per la prima volta in CVE-2008-4106, che era correlata a WordPress CMS.
Come funzionano gli attacchi di troncamento SQL
Questo attacco funziona a causa del troncamento dell'input dell'utente nei database utilizzando le funzioni di 'selezione' e 'inserimento'.
- Quando viene fornito un input nel campo del modulo, la funzione 'select' verifica la ridondanza corrispondente agli input nel database.
- Dopo aver verificato la ridondanza, la funzione "inserimento" controlla la lunghezza dell'input e l'input dell'utente verrà troncato se la lunghezza supera.
Supponiamo che uno sviluppatore crei la tabella "utenti" tramite la seguente query:
creare utenti tabella(user_id INT NOT NULL AUTO_INCREMENT,
nome_utente VARCHAR(20) NOT NULL,
password VARCHAR(40) NOT NULL,
CHIAVE PRIMARIA ( user_id )
);
Utilizzando questo schema, se lo sviluppatore crea un account amministratore con quanto segue:
nome_utente = 'amministratore'password = “secret_p4ssw0ord”
Ovviamente queste credenziali non sono pubbliche. C'è solo un account amministratore nel database e se un utente malintenzionato tenta di registrare un altro account con il nome utente "admin", l'attaccante fallirà a causa dei controlli di ridondanza del database. L'attaccante può ancora ignorare quel controllo di ridondanza per aggiungere un altro account amministratore sfruttando la vulnerabilità SQL Truncation. Supponiamo che l'attaccante registri un altro account con il seguente input:
Nome_utente = 'adminxxxxxxxxxxxxxxxrandom'(x sono gli spazi)
&
Password = "Utente casuale"
Il database prenderà 'user_name' (26 caratteri) e verificherà se questo esiste già. Quindi, l'input user_name verrà troncato e 'admin '('admin' con spazio) verrà inserito nel database, risultando in due utenti admin duplicati.
L'attaccante è quindi in grado di creare un utente "admin" con la propria password. Ora, il database ha due voci admin 'user_name', ma con password diverse. L'attaccante può accedere con le credenziali appena create per ottenere un pannello di amministrazione perché entrambi i nomi utente "admin" e "admin" sono uguali per il livello del database. Ora, esamineremo un esempio di attacco pratico.
Attacco campione
In questo esempio, prenderemo uno scenario dal sito web overthewire.organizzazione. La comunità di overthewire fornisce CTF di wargame su cui possiamo mettere in pratica i nostri concetti di sicurezza. Lo scenario del troncamento SQL si verifica nel gioco natas Livello 26->27. Possiamo accedere al livello utilizzando quanto segue:
URL: http://natas27.natas.laboratori.overthewire.organizzazioneNome utente: natas27
Parola d'ordine: 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ
Questo livello è disponibile su: https://overthewire.org/wargames/natas/natas27.html. Ti verrà mostrata una pagina di accesso che è vulnerabile a un attacco SQL Truncation.
Dopo aver ispezionato il codice sorgente, vedrai che la lunghezza del nome utente è 64, come mostrato di seguito.
Esiste già un utente chiamato 'natas28'. Il nostro obiettivo è creare un altro utente denominato 'natas28' utilizzando l'attacco SQL_truncation. Quindi, inseriremo natas28, seguito da 57 spazi e un alfabeto casuale (nel nostro caso, a), nome utente e qualsiasi password. La lettera 'a' non è visibile nello screenshot a causa del nome utente lungo 65 caratteri. Dopo la creazione dell'account utente, sarai in grado di vedere il 'un.'
Se il database contiene vulnerabilità sql_truncation, il database dovrebbe ora avere due nomi utente "natas28". Un nome utente conterrà la nostra password. Proviamo ad inserire le credenziali nella pagina di login.
Ora, abbiamo effettuato l'accesso come utente 'natas28'.
Mitigazione
Per mitigare questo attacco, dovremo considerare più fattori.
- Non dovremmo consentire la duplicazione di identità critiche come il nome utente. Dovremmo rendere queste identità chiavi primarie.
- La funzione troncare dovrebbe essere implementata per tutti i campi dei moduli frontend, così come il codice backend, in modo che i database ricevano input troncati.
- La modalità rigorosa dovrebbe essere abilitata a livello di database. Senza la modalità rigorosa abilitata, i database forniscono solo avvisi nel back-end, ma salvano comunque i dati duplicati. Con la modalità rigorosa, i database danno errori in caso di duplicazione ed evitano il salvataggio dei dati.
Ad esempio, controlliamo la modalità rigorosa utilizzando la seguente query:
mysql> seleziona @@sql_mode
Creeremo un database e la tabella "utenti".'
mysql> prova CREA DATABASEQuery OK, 1 riga interessata (0.02 secondi)
mysql> Usa test
Database modificato
mysql> CREATE TABLE utenti (nome utente VARCHAR(10), password VARCHAR(10));
Query OK, 0 righe interessate (0.05 secondi)
Successivamente, creeremo un utente amministratore con credenziali utilizzando la query INSERT.
mysql> INSERT INTO users VALUES ('admin', 'password1');Query OK, 1 riga interessata (0.01 secondi)
Possiamo vedere le informazioni della tabella "utenti" usando l'opzione "seleziona * da utenti" users.
La lunghezza del nome utente è di 10 caratteri. Ora proveremo l'attacco di troncamento SQL.
Quando proviamo a inserire quanto segue:
Nome utente = 'adminxxxxa'(x sono gli spazi)
&
Password = 'pass2'
Riceveremo un errore, il che significa che la modalità rigorosa è totalmente efficace.
mysql> INSERT INTO users values('admin a', 'pass2')ERRORE 1406 (22001): dati troppo lunghi per la colonna "nome utente" alla riga 1
Senza la modalità rigorosa abilitata, il database genererà avvisi, ma inserirà comunque i dati nella tabella.
Conclusione
Gli aggressori possono ottenere l'accesso ad account con privilegi elevati se la vulnerabilità sql_trunction esiste nella tua applicazione. L'attaccante può facilmente ottenere informazioni su un nome utente e sulla sua lunghezza del database utilizzando i campi critici, quindi creare lo stesso nome utente, seguito da spazi e lettere casuali dopo la lunghezza minima, con conseguente creazione di più account con privilegi elevati. Questa vulnerabilità è critica, ma può essere evitata se si prendono alcune precauzioni di sicurezza, come l'attivazione della modalità rigorosa per gli input dell'utente e l'impostazione del campo sensibile come chiave primaria nel database.
