L’Approccio di DataSunrise alla Configurazione delle Sanzioni per il Rilevamento di SQL Injection

L’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 SQL injection attraverso un sistema di punti di penalità. Questo articolo esplorerà come DataSunrise configura le sanzioni per i diversi tipi di modelli di SQL injection e fornirà esempi di ognuno.

Sistema dei Punti di Penalità

Il sistema dei punti di penalità di DataSunrise assegna un valore numerico a vari componenti di una query SQL che possono indicare una potenziale iniezione. Quando la somma di queste sanzioni supera una soglia predefinita, DataSunrise agisce, sia registrando un avviso (Regola di Audit) o bloccando completamente la query (Regola di Sicurezza).

Esempi di Modelli di SQL Injection e Sanzioni

Sanzione per Commenti

Uno dei compiti principali per un attaccante quando cerca di effettuare una iniezione è quello di cambiare radicalmente la richiesta. Per fare ciò, deve disabilitare/tagliare quella parte della richiesta che non controlla o che gli impedirà di eseguire l’iniezione. A tal fine, viene aggiunto un codice all’iniezione che commenterà quella parte della richiesta situata dopo il blocco iniettato. Ecco alcuni esempi.

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

Iniezione nel parametro username: admin’–

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

Se riesce, questo permetterà il login come utente admin perché il resto della query SQL dopo ‘–’ sarà ignorato.

Esempio 2. Esempi Classici di Attacchi SQL Injection con Commenti Inline

ID value: 10; DROP TABLE members /*

Semplicemente elimina altre cose alla fine della query. Come 10; DROP TABLE members —

Pertanto, la presenza di commenti nella richiesta è uno dei segni di una potenziale iniezione.

Una Parola Chiave in una Sanzione per Commenti

Continuando il tema dei commenti in una richiesta, possiamo dire che i commenti ordinari possono essere trovati abbastanza spesso in richieste legittime. Per 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 la richiesta è stata generata o altre informazioni di meta. Pertanto, un ulteriore segno che un commento è sospetto è la presenza di parole chiave SQL come AND/OR/SELECT, ecc.

Per esempio, nell’espressione SQL discussa sopra

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

La parola chiave AND è stata commentata.

Sanzione per Query Doppia (Stacking Queries)

Lo 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--`

Quando riesce, questo terminerà una query e ne inizierà 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 insolite.

Penalità OR + Espressione Costante

Spesso, per utilizzare un’iniezione o un’altra, un attaccante deve creare una condizione tale che sia vera (TRUE). E per questo, il modo più semplice può essere un’operazione OR con un valore che è sempre TRUE. Per 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, e 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 l’iniezione. Lo stesso vale per le espressioni che restituiscono sempre TRUE o FALSE.

Penalità UNION

Le nostre ricerche hanno mostrato che gli attaccanti informatici utilizzano 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, viene generalmente verificata la possibilità di accedere ad altre tabelle

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

Quando esegui un attacco SQL injection UNION, ci sono due metodi efficaci per determinare quanti colonne vengono restituite dalla query originale.

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

' 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, come:

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

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

Per ridurre le possibilità di rilevare un’iniezione, DataSunrise rileva UNION simili utilizzati quando si scansionano applicazioni vulnerabili e assegna punti di penalità aggiuntivi.

Conversione Sospetta: Attacco di Errore

La tecnica di SQL Injection basata su errore forza il database a generare un errore, dando all’attaccante o tester informazioni su cui affinare la propria iniezione.

Per forzare un’applicazione a generare una richiesta che verrebbe eseguita con un errore, vengono utilizzate molte tecniche diverse. Una di queste è operazioni che tentano esplicitamente o implicitamente di convertire un valore in 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 Ciechi quando l’attaccante può solo scoprire se si è verificato un errore o meno.

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

Concatenazione di Singoli Caratteri per Molti Tipi di Attacchi

Un altro modello spesso utilizzato negli attacchi è l’uscita dai dati restituiti. Questo è spesso necessario quando il contenuto della pagina attaccata cambia frequentemente, e lo script di verifica dell’iniezione automatica deve utilizzare marcatori speciali per trovare il payload (i dati preziosi che vogliamo estrarre).

Per 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 progettazioni sono sospette per DataSunrise.

Chiamata a Funzione Sospetta

In qualsiasi applicazione di produzione decente, generalmente non puoi vedere alcuna risposta di errore sulla pagina. Questo esclude l’estrazione diretta dei dati attraverso attacchi UNION o basati su errori. In questi casi, devi utilizzare iniezioni SQL cieche per estrarre i dati. Esistono due principali tipi di iniezioni SQL cieche.

Iniezioni cieche normali. Non puoi vedere la risposta direttamente sulla pagina, ma puoi comunque determinare il risultato di una query in base a un codice di stato della risposta o dell’HTTP.

Iniezioni completamente cieche. Non puoi vedere gli effetti della tua iniezione in alcun tipo di output. Questo è meno comune, per esempio quando stai iniettando in una funzione di registrazione o simile.

Nelle iniezioni cieche normali, puoi utilizzare dichiarazioni IF o abusare delle clausole WHERE nelle query, che è generalmente la strada più facile. Per le iniezioni completamente cieche, devi utilizzare qualche tipo di funzione di attesa e analizzare i tempi di risposta.

Esempi di funzioni di attesa/timeout disponibili includono:

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

DataSunrise assegna punti di penalità aggiuntivi se la richiesta contiene query simili che sono spesso utilizzate negli attacchi.

Condizione Sospetta per Verificare l’Attacco Cieco Booleano

L’iniezione SQL cieca è un tipo di SQL injection dove 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. L’iniezione SQL cieca è anche chiamata iniezione SQL inferenziale.

Ci sono due tipi di iniezioni SQL cieche: basate su booleani e basate su tempo.

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

Ecco un esempio di 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 assegna anche punti di penalità se vengono rilevati segni di tali query.

Penalità per Conteggio Sospetto

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

Il punto è che se l’iniezione SQL basata su tempo è disponibile, l’attaccante ha bisogno di distinguere in qualche modo tra due rami di esecuzione del codice. Per farlo, viene eseguita una richiesta in uno dei rami, che richiede molto tempo. Per esempio, contando il numero di righe in un join di due o più tabelle. Durante il join, le linee vengono moltiplicate e si ottengono molte linee. E COUNT si esegue abbastanza a lungo da essere notato dallo script. Puoi leggere più dettagli qui. In quell’articolo, troverai il SLEEP(5), ma è solo un gioco da ragazzi.

Molte persone hanno già dimostrato questo, e per questa ragione, usano metodi più sofisticati sotto forma di COUNT+JOIN, che abbiamo descritto sopra. Nella pratica normale, tale richiesta, che è parte di una richiesta più complessa, non è utilizzata e pertanto questo può servire come uno dei segni di iniezione.

Conclusione

L’approccio di DataSunrise alla configurazione delle sanzioni per il rilevamento di SQL injection presenta una strategia completa e proattiva per salvaguardare 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 potenziali tentativi di iniezione. Attraverso esempi che illustrano diversi modelli di SQL injection e le sanzioni associate, questo articolo dimostra la versatilità e l’efficacia dei meccanismi di rilevamento di DataSunrise.

In sostanza, la configurazione meticolosa delle sanzioni per il rilevamento di SQL injection da parte di DataSunrise sottolinea il suo impegno nel fornire soluzioni di sicurezza robusta per i database. Sfruttando tecniche di rilevamento avanzate e affinando continuamente il suo sistema di penalità, DataSunrise consente alle organizzazioni di proteggere efficacemente i propri asset di dati critici contro gli attacchi SQL injection.