Una query sql con input e parametro utente può essere soggetta a SQL injection?

Question

Una query sql con input e parametro utente può essere soggetta a SQL injection?

#1 da (5 voti)

0

Mi sono imbattuto in qualche codice in un'applicazione in cui (certi) utenti sono autorizzati a inserire le condizioni. Inoltre, esiste una parte della condizione where impostata come query parametrizzata.

per esempio:.

select foo from bar where <user generated> and foo = ?

(Oltre a questo la porzione generata dall'utente viene eseguita attraverso un filtro di ordinamenti prima che la query sia costruita che consente solo determinati input)

L'applicazione utilizza JDBC contro Mysql (Connector / J). Questo driver fa, per quanto posso capire, la pre-elaborazione delle istruzioni preparate dal lato client. Se l'iniezione sql è possibile, sarebbe possibile "uscire" dalla condizione parametrizzata in cui? Forse con sottoquery?

sql-injection

posta sesamoid 06.01.2014 - 14:37

fonte

1 risposta

Leggi altre domande sui tag sql-injection

Utilizzo della stessa stringa di base per una password in diversi accessi diversi [duplicato] Come impedire ad altri host sulla stessa LAN di vedere il mio IP e il nome host?

score 5 · Accepted Answer

Sì. Praticamente qualsiasi query sql che concatena l'input dell'utente grezzo o imperfettamente protetto può essere vulnerabile all'iniezione.

Ci sono alcune restrizioni. Ad esempio, l'input dell'utente deve essere abbastanza lungo da essere un attacco praticabile (l'iniezione a singolo carattere potrebbe non essere sufficiente, dato l'uso specifico dell'affermata dichiarazione in questione). Devono essere dati utilizzabili per l'attacco (la convalida dell'input può limitare l'input a una lista bianca di valori sicuri, come {1, 2, 3}). Non può essere codificato in un'altra forma benigna (come basese64 che codifica i dati dell'utente).

La regola generale da usare è "se è concatenato, è una vulnerabilità se non provato diversamente". Generalmente è più economico, veloce e facile da correggere che dimostrare che non è una vulnerabilità, quindi dovrebbe essere corretto.