L’Approccio di DataSunrise alla Configurazione delle Penalità per la Rilevazione di SQL Injection

SQL injection è una minaccia prevalente per la sicurezza nel database, dove gli attaccanti manipolano le query SQL per ottenere accesso non autorizzato ai dati. DataSunrise, una soluzione di sicurezza nel database, offre un meccanismo robusto per rilevare e prevenire attacchi di SQL injection attraverso un sistema di punti di penalità. Questo articolo esplorerà come DataSunrise configura le penalità per diversi tipi di pattern di SQL injection e fornirà esempi di ciascuno.

Sistema di Punti di Penalità

Il sistema di punti di penalità di DataSunrise assegna un valore numerico a vari componenti di una query SQL che possono indicare una potenziale injection. Quando la somma di queste penalità supera una soglia predefinita, DataSunrise prende provvedimenti, registrando un avviso (Regola di Audit) o bloccando la query del tutto (Regola di Sicurezza).

Esempi di Pattern di SQL Injection e Penalità

Penalità del Commento

Uno dei compiti base per un aggressore quando cerca di effettuare un’injection è cambiare radicalmente la richiesta. Per questo, ha bisogno di disabilitare/eliminare quella parte della richiesta che non controlla o che gli impedirebbe di effettuare l’injection. A tale scopo, viene aggiunto codice all’injection che commenterà quella parte della richiesta situata dopo il blocco iniettato. Ecco alcuni esempi.

1 Esempio. Un esempio comune è il login come admin:

Injection nel parametro dell’username: admin’–

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

Se riuscito, questo ti connetterà come utente admin perché il resto della query SQL dopo ‘–’ sarà ignorato.

2 Esempio. Campioni Classici di Attacco SQL Injection con Commento Inline

ID valore: 10; DROP TABLE members /*

Basta eliminare altre cose alla fine della query. Come 10; DROP TABLE members –

Perciò, la presenza di commenti nella richiesta è uno dei segni di una potenziale injection.

Penalità di una Parola Chiave in un Commento

Continuando il tema dei commenti in una richiesta, possiamo dire che i commenti ordinari possono essere trovati abbastanza spesso in richieste legittime. Ad esempio, molti IDE utilizzati dagli sviluppatori aggiungono automaticamente l’ora corrente all’inizio della richiesta sotto forma di commento o la versione dell’IDE in cui è stata generata la richiesta o altre meta informazioni. Pertanto, un ulteriore segno che un commento è sospetto è la presenza di parole chiave SQL come AND/OR/SELECT, ecc.

Ad esempio, nell’espressione SQL discussa sopra

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

La parola chiave AND era stata commentata.

Penalità della Doppia Query (Stacking Queries)

Stacking significa eseguire più di una query in una transazione. Questa tecnica può essere utile ma funziona solo per alcune combinazioni di server di database e metodi di accesso:

SELECT * FROM members; DROP members--`

Se riuscito, questo finirà una query e ne avvierà un’altra.

Non tutti i database supportano l’esecuzione di due o più espressioni in una query, ma dove è supportato, tali casi devono essere controllati.

DataSunrise non genera errori se vengono utilizzate espressioni di configurazione (SET e simili) o query di dichiarazione di variabili in un’espressione. Tali richieste non sono inusuali.

Penalità di OR + Penalità di Espressione Costante

Spesso, per usare un’injection o un’altra, un attaccante deve creare una condizione tale da essere vera (TRUE). Per questo, il modo più semplice può essere un’operazione OR con un valore che è sempre TRUE. Ad esempio, come nell’esempio: https://insecure-website.com/products?category=Gifts’+OR+1=1–

Questo risulta nella query SQL:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

In questo caso, la query mostrerà tutte le categorie, non solo quelle che dovrebbe.

Ovviamente, l’operazione OR è comune e popolare nello sviluppo di applicazioni, ma insieme ad altri segni può aiutare a rilevare un’injection. Lo stesso vale per le espressioni che ritornano sempre TRUE o FALSE.

Penalità di Union

La nostra ricerca ha dimostrato che gli aggressori informatici usano strumenti automatizzati che li aiutano a identificare la possibilità teorica di sfruttare una particolare vulnerabilità. Se è possibile aggiungere un’espressione aggiuntiva a una query vulnerabile, allora solitamente viene verificata la possibilità di accesso ad altre tabelle

select id, id from products where name = 'Gifts' UNION SELECT NULL, NULL from SYS.USERS --'

Quando si esegue un attacco SQL injection UNION, esistono due metodi efficaci per determinare quante colonne vengono restituite dalla query originale.

Un metodo prevede l’invio di una serie di payload UNION SELECT specificando un diverso numero di valori null:

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL–, ecc.

Se il numero di null non corrisponde al numero di colonne, il database restituisce un errore, ad esempio:

Tutte le query combinate usando un operatore UNION, INTERSECT o EXCEPT devono avere un numero uguale di espressioni nelle loro liste target.

Un attaccante usa NULL come valori restituiti dalla query SELECT iniettata perché i tipi di dati in ciascuna colonna devono essere compatibili tra la query originale e quella iniettata. NULL è convertibile in ogni tipo di dato comune, quindi massimizza la possibilità che il payload abbia successo quando il conteggio delle colonne è corretto.

Per ridurre le possibilità di rilevamento di un’injection, DataSunrise rileva similitudini nelle UNION utilizzate quando vengono scansionate applicazioni vulnerabili e assegna punti di penalità aggiuntivi.

Conversione Sospetta: Attacco di Errore

La tecnica di Iniezione SQL basata su Errore forza il database a generare un errore, dando all’attaccante o al tester informazioni su cui affinare la loro injection.

Per forzare un’applicazione a generare una richiesta che verrà eseguita con un errore, vengono utilizzate molte tecniche differenti. Una di queste è costituita da operazioni che tentano di convertire esplicitamente o implicitamente un valore a un tipo a cui non può essere convertito:

‘ and 1=convert(int,(select top 1 table_name from information_schema.tables))--

In questo caso, verrà generato un errore, il cui testo includerà un valore di testo dalla tabella di sistema information_schema.tables.

Tuttavia, questa tecnica non è limitata a tali attacchi. Questa tecnica può anche essere utilizzata per attacchi basati su Errore Cieco quando l’attaccante può solo scoprire se c’è stato un errore o no.

Probabilmente il tipo di verifica più difficile dal punto di vista dell’implementazione. La ragione di ciò è che esiste un enorme numero di possibilità per causare un errore.

Concatenazione di Singoli Caratteri per Molti Tipi di Attacchi

Un altro pattern che viene spesso utilizzato negli attacchi è l’escaping dei dati restituiti. Questo è spesso necessario quando il contenuto della pagina attaccata cambia frequentemente e lo script di verifica automatica della injection deve utilizzare marcatori speciali per trovare il payload (i dati preziosi che vogliamo estrarre).

Ad esempio,

AND 3516=CAST((CHR(113)||CHR(106)||CHR(122)||CHR(106)||CHR(113))||(SELECT (CASE WHEN (3516=3516) THEN 1 ELSE 0 END))::text||(CHR(113)||CHR(112)||CHR(106)||CHR(107)||CHR(113)) AS NUMERIC)

Tali strutture sono sospette per DataSunrise.

Chiamata a Funzione Sospetta

In qualsiasi applicazione di produzione decente, generalmente non si possono vedere risposte di errore sulla pagina. Questo esclude l’estrazione diretta dei dati attraverso attacchi UNION o basati su errore. In questi casi, è necessario usare iniezioni SQL cieche per estrarre i dati. Ci sono due tipi fondamentali di iniezioni SQL cieche.

Iniezioni cieche normali. Non si può vedere la risposta direttamente sulla pagina, ma si può ancora determinare il risultato di una query basandosi su una risposta o un codice di stato HTTP.

Iniezioni completamente cieche. Non si può vedere gli effetti della propria injection in nessun tipo di output. Questo è meno comune, ad esempio quando si inietta in una funzione di log o simile.

In normali iniezioni cieche, si possono usare istruzioni IF o abusare di clausole WHERE nelle query, che è generalmente la via più semplice. Per iniezioni completamente cieche, è necessario utilizzare una sorta di funzione di attesa e poi analizzare i tempi di risposta.

Esempi di funzioni disponibili di attesa/timeout includono:

WAITFOR DELAY '0:0:10' in SQL Server
BENCHMARK() e sleep(10) in MySQL
pg_sleep(10) in PostgreSQL

DataSunrise assegna punti di penalità aggiuntivi se nella richiesta sono presenti query simili che vengono spesso utilizzate negli attacchi.

Condizione Sospetta per Verificare un Attacco Cieco Booleano

SQL injection cieca è un tipo di SQL injection in cui l’attaccante non riceve una risposta ovvia dal database attaccato e invece ricostruisce la struttura del database passo dopo passo osservando il comportamento del server del database e dell’applicazione. SQL injection cieca è anche chiamata SQL injection inferenziale.

Esistono due tipi di iniezioni SQL cieche: basate su Booleani e basate sul tempo.

In questo tipo di attacco, non si può ottenere il risultato completo. L’attaccante arriva a ottenere ciecamente il contenuto delle tabelle di suo interesse, lettera per lettera. Questo può richiedere molto tempo e richiede una buona automazione.

Ecco un esempio di una tale richiesta.

ORD(MID((SELECT grantee FROM(SELECT DISTINCT(grantee) FROM INFORMATION_SCHEMA.USER_PRIVILEGES LIMIT 0, 1) AS caou), 22, 1)) > 39--MnqX'

DataSunrise emette anche punti di penalità se vengono rilevati segni di tali query.

Penalità di Conteggio Sospetto

Questi sono i punti che DataSunrise assegna per blocchi sospetti in SQL sotto forma di SELECT count(*) FROM t1,t2.

Il punto è che se è disponibile SQL Injection basata sul tempo, l’attaccante deve in qualche modo distinguere tra due rami di esecuzione del codice. Per fare ciò, viene eseguita una richiesta in uno dei rami che richiede molto tempo. Ad esempio, contando il numero di righe in un join di due o più tabelle. Durante il join, le righe si moltiplicano e si ottengono molte righe. E COUNT richiede abbastanza tempo perché lo script se ne accorga. Puoi leggere più dettagli qui. In quell’articolo, troverai il SLEEP(5), ma è solo per principianti.

Molte persone hanno già provato ciò, e per questo motivo usano metodi più sofisticati sotto forma di COUNT+JOIN, che abbiamo descritto sopra. Nella pratica normale, una tale richiesta, che fa parte di una richiesta più complessa, non viene utilizzata e quindi questo può servire come uno dei segni di injection.

Conclusione

L’approccio di DataSunrise alla configurazione delle penalità per la rilevazione di SQL injection presenta una strategia completa e proattiva per proteggere i database contro questa minaccia pervasiva. Utilizzando un sistema di punti di penalità che valuta vari aspetti delle query SQL, DataSunrise identifica e mitiga efficacemente i tentativi di injection potenziali. Attraverso esempi che illustrano diversi pattern di SQL injection e le penalità associate, questo articolo dimostra la versatilità e l’efficacia dei meccanismi di rilevazione di DataSunrise.

In sostanza, la meticolosa configurazione di DataSunrise delle penalità per la rilevazione di SQL injection sottolinea il suo impegno a fornire soluzioni di sicurezza nel database robuste. Sfruttando tecniche di rilevazione avanzate e raffinando continuamente il suo sistema di penalità, DataSunrise abilita le organizzazioni a proteggere efficacemente i loro asset cruciali di dati contro gli attacchi di SQL injection.