Come funziona l'iniezione SQL attraverso l'URL?

Question

Come funziona l'iniezione SQL attraverso l'URL?

#1 da (10 voti)
#2 da (5 voti)

10

Mi chiedo come funziona l'iniezione SQL attraverso l'URL con SQL nel parametro. Supponiamo che abbia un database con una tabella denominata mytable . Quando ottengo un ID dal metodo POST lo metto in questa query:

SELECT * FROM 'mytable' WHERE id='POST[id]'

Anche se l'utente inserisce SQL come:

SELECT * FROM 'mytable'

È diventato qualcosa del genere:

SELECT * FROM 'mytable' WHERE id='SELECT * FROM 'mytable'

Quindi restituisce solo:

You have an error in your SQL syntax.

Quindi come funziona questo tipo di attacco? In che modo l'utente malintenzionato può modificare la query senza causare un errore di sintassi?

sql-injection web-application

posta Anders 03.06.2013 - 19:55

fonte

2 risposte

Leggi altre domande sui tag sql-injection web-application

Come posso identificare che la mia pagina è richiesta dal robot, ma non dal browser dell'utente? Cosa fa l'applicazione Blue Coat Unified Agent?

score 10 · Answer 1

Il punto dell'iniezione SQL è modificare la query in cui si trova la variabile.

Usiamo la query che hai scritto come esempio. Se la variabile id contiene qualcosa di simile a questo e non è sanificata correttamente:

' OR 1=1#

Restituirebbe ogni singola riga perché è stata modificata in questo modo:

SELECT * FROM 'mytable' WHERE id='' OR 1=1#'

Il trucco per evitare l'errore di sintassi è commentare il resto della query (il carattere # lo fa in questa situazione.

score 5 · Answer 2

Sfruttare le iniezioni SQL è l'arte di fornire parametri che, una volta incorporati in un'istruzione SQL, producono una sintassi dell'istruzione SQL valida mentre cambiano la semantica voluta dallo sviluppatore in una parte che è proficua per un utente malintenzionato.

A seconda del DMBS e del tipo di istruzione, in cui l'iniezione è possibile, i risultati di un'iniezione SQL di successo variano dalla divulgazione delle informazioni (lettura di dati arbitrari, file locali), tramite manipolazione dei dati (inserimento, eliminazione o alterazione arbitraria) dati, scrivendo file locali), fino all'esecuzione arbitraria dei comandi.

Il DBMS e la dichiarazione influenzano anche quali tecniche possono essere utilizzate durante lo sfruttamento. Se l'API di connessione non consente l'esecuzione di più istruzioni (le cosiddette "query impilate"), il spesso citato Robert';DROP TABLE Students; -- non avrebbe effetto. In tal caso, anche si limita agli effetti collaterali del particolare tipo di istruzione in cui si verifica l'iniezione : se è un% dichiarazione diSELECT, è molto probabile che sia possibile leggere solo i dati, ma non scrivere o cancellare dati.

E infine, dipende anche dal feedback che viene dato all'attaccante in merito al risultato dell'istruzione eseguita. I messaggi di errore, in particolare quelli generati da un'API di connessione o dal linguaggio di programmazione, sono spesso piuttosto tecnici e dettagliati e possono rivelare informazioni critiche, ad esempio parti dell'istruzione non riuscita come "Hai un errore nella sintassi SQL vicino a '...'". Tali messaggi possono fornire utili informazioni agli utenti malintenzionati sul contesto in cui avviene l'iniezione (tipo di istruzione, tipo di clausola, livello di nidificazione parentesi, ecc.).

Nel tuo esempio un semplice id=' OR '1'='1 risulterebbe nella seguente affermazione:

SELECT * FROM 'mytable' WHERE id='' OR '1'='1'

Con quest'ultima espressione '1'='1' verranno selezionate tutte le righe. Un'estensione a questo sarebbe utilizzare una sottoquery per leggere dati arbitrari in modo cieco:

SELECT * FROM 'mytable' WHERE id='' OR EXISTS (SELECT * FROM users WHERE name='admin' AND password LIKE 'a%') AND '1'='1'

Qui tutte le righe saranno selezionate solo se esiste un utente admin la cui password inizia con a , altrimenti non verrà selezionata alcuna riga. Questa tecnica è chiamata 'cieca booleana'.