Quali sono i problemi di SQL injection delle query parametrizzate?

Question

Quali sono i problemi di SQL injection delle query parametrizzate?

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

11

Ho scritto del codice per generare una query SQL in ASP classic. Non sono sicuro che sia sicuro o meno:

Set adoCon = Server.CreateObject("ADODB.Connection")
adoCon.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath(dbfile)
strSQL = "SELECT * FROM Table WHERE name_field LIKE ?"

Set cmd1 = Server.CreateObject("ADODB.Command") 
cmd1.ActiveConnection = adoCon 
cmd1.CommandText = strSQL 
cmd1.CommandType = 1 'adCmdText 
cmd1.Parameters(0) =  Request("odQuery") & "%"  
Set rs = cmd1.Execute()

Poi vado a visualizzare i risultati da rs .

Questo è sicuro? (So per esempio che posso mettere un segno di percentuale all'inizio di odQuery e fare in modo che il codice restituisca più record).

sql-injection web-application appsec databases classic-asp

posta Flash 15.08.2011 - 08:01

fonte

2 risposte

Leggi altre domande sui tag sql-injection web-application appsec databases classic-asp

Questo snippet di codice è sufficiente per l'hash della password e il sale Perché OpenVPN richiede la condivisione sicura di certificati con i clienti?

score 10 · Answer 1

Stai già utilizzando query parametrizzate che ti proteggono dall'iniezione di parti SQL, supponendo che utilizzi sempre i parametri per i dati non attendibili.

Come hai detto, lascia il problema dei caratteri jolly negli operatori che li supportano. Cioè, se stai usando "=" invece di LIKE, il problema non si presenterà. Nella maggior parte dei casi, in cui LIKE viene utilizzato intenzionalmente, è richiesta una ricerca con i dati forniti dall'utente. Quindi aggiungere altri caratteri jolly non è un problema.

L'aggiunta di un carattere jolly nella parte anteriore, tuttavia, potrebbe avere un impatto significativo sulle prestazioni poiché gli indici dei prefissi non possono essere utilizzati in modo efficiente. Quindi, se il set di dati è enorme, potresti volerli filtrare. I wildcar standard sono% e _, ma alcuni database supportano caratteri aggiuntivi come *.

score 6 · Answer 2

Questo non è sicuro, per diversi motivi - che probabilmente non stai nemmeno considerando.

Iniziamo in alto:

Stai usando ASP "classic". Questa piattaforma è nota per essere insicura.
Il tuo provider è Microsoft.Jet - Suppongo che si stia connettendo a un file MS Access ... Ancora una volta, non un back-end sicuro. Per esempio. nessuna autenticazione al database, problemi con un file condiviso, ecc.
Non so se te ne rendi conto, se è intenzionale, o se è importante nella tua applicazione , ma stai prendendo il parametro da Request("odQuery") - che potrebbe essere Request.Forms("odQuery") , Request.QueryString("odQuery") , ecc ... L'autore dell'attacco può abusare di questo, ad es creando un link (anziché un POST) e affidando a qualcun altro (ad es. privilegi più elevati) l'invio.
Sto speculando qui, ma a giudicare dal codice precedente (e dal fatto che si tratta di "ASP classico"), " I then go on to display the results from rs " suppongo che molto probabilmente si tradurrà in XSS (Cross-Site scripting).
Ora parliamo di SQL Injection - come ha sottolineato @Hendrik nella sua risposta, i caratteri jolly sono un problema. Questo potrebbe avere 2 problemi:
- Accesso ai dati a cui l'utente non dovrebbe avere accesso
- Creazione di un attacco DoS (Denial of Service), causando molte ricerche intensive di calcolo, come mettere il carattere jolly in primo piano in dataset di grandi dimensioni (come sottolineato da @Hendrik).

Se stai cercando in particolare un modo per eseguire una query secondaria, sei al sicuro da questo, almeno su Access (alcuni vantaggi dal non utilizzare un DB con funzionalità complete ...).
Tuttavia, esistono altre forme di SQL Injection (come sopra) e ancora più modi di essere insicuri.