Quali pericoli ci sono nel consentire l'input dell'utente di parti di una stringa di connessione ODBC?

Question

Quali pericoli ci sono nel consentire l'input dell'utente di parti di una stringa di connessione ODBC?

#1 da (3 voti)
#2 da (2 voti)

4

Sto sviluppando un'applicazione che consente all'utente di inserire nomi host, nomi di database, nomi utente e password per l'accesso al database. L'applicazione costruirà una stringa di connessione ODBC riempiendo i segnaposto. In C, ciò si tradurrebbe in qualcosa di simile:

snprintf(connStr, sizeof(connStr),
         "DRIVER={%s};SERVER={%s};DATABASE={%s};UID={%s};PWD={%s}",
         myDriver, hostName, dbName, userName, passWord);

Per prima cosa ho pensato - ho bisogno di asportare il ";" personaggio da tutto. (E indica agli utenti che le loro password non possono contenere il punto e virgola).

Sono vulnerabile a qualche tipo di input ostile in questo caso? (Prima che tu chieda, sì, controllerò l'input troppo grande. Puoi presupporre che il buffer connStr sarà sufficiente, oppure userò un linguaggio di livello superiore con tipi di stringhe gestite.)

databases injection

posta JCCyC 30.03.2011 - 01:34

fonte

2 risposte

2

Bene, non so se questo codice è vulnerabile. Non so molto sul formato delle stringhe di connessione ODBC.

Ma, ad essere onesti, quel codice emana cattivi odori. Anche se non conosco un attacco specifico, odora come un potenziale rischio per la sicurezza. Ha l'odore di una vulnerabilità di iniezione che aspetta di accadere.

Quanto sei sicuro di conoscere l'elenco completo di tutti i metacaratteri che il driver del database potrebbe interpretare durante l'elaborazione della stringa ODBC? (Tratta i backslash come escape? Cosa succede se uno dei parametri definiti dall'utente include una parentesi graffa chiusa, alcuni elementi e un'altra parentesi graffa aperta? Cosa succede se un parametro include una parentesi graffa aperta ma non chiusa e un parametro successivo include una stretta parentesi graffa, cosa succede?) Quanto sei sicuro di sapere quali codifiche dei caratteri potrebbero utilizzare il driver del database durante l'analisi della stringa di connessione? Sei sicuro che questo non cambierà mai, non per nessuna versione futura del database che utilizzi o per qualsiasi altro database in cui potresti mai passare in futuro? So che non sarei sicuro di conoscere le risposte a queste domande. Forse sai più di me.

Se fossi in me, non mi espongo a questi rischi. Sarei diffidente Sembra inutile prendere questi rischi. Invece, suggerirei di creare una whitelist di caratteri che sembrano OK e limitare tutte quelle stringhe a utilizzare solo caratteri all'interno della whitelist. Forse questa è una cautela inutile, ma è quello che farei.

risposta data 31.03.2011 - 09:24

fonte

Leggi altre domande sui tag databases injection

Quando dovrei generare nuove chiavi pubbliche e private usando RSA? Node.js REST server in esecuzione come root

score 3 · Accepted Answer

Per espandersi leggermente su uno dei punti @ Sigtran, il filtro su caratteri speciali deliminator è ovviamente un controllo chiave quando si protegge dagli attacchi di iniezione, tuttavia è anche consigliabile proteggere dal potenziale di codifica creativa utilizzando il più restrittivo possibile un approccio white-list invece di sostituire semplicemente caratteri come; 'ecc. Alcune espressioni regolari come questa potrebbero forse essere utilizzate (se non si interrompe la funzionalità legit con solo alpha / num / trattini, ovviamente):

/ [^ A-Za-z-_0-9] / g, ""