Protezione dell'iniezione SQL del secondo ordine

Un'iniezione SQL di secondo ordine è un'iniezione in cui il carico utile è già memorizzato nel database (invece di essere consegnato in un parametro GET). In questo senso è in qualche modo simile all'XSS memorizzato (e l'ordinaria iniezione SQL di "primo ordine" sarebbe analoga a quella del XSS riflesso).

Come funziona? Diciamo che permetti agli utenti di scegliere qualsiasi nome utente. Quindi un utente malintenzionato potrebbe scegliere il nome '; DROP TABLE Users; -- . Se in modo ingenuo concateni questo nome utente nella tua query SQL per recuperare informazioni su quell'utente hai un problema:

sql = "SELECT * FROM Users WHERE UserName = '" + $username + "'";

Quindi, come ti occupi di questo?

Usa sempre i quesiti parametrizzati, sempre, sempre, sempre. Tratta tutte le variabili come dati utente non attendibili anche se provengono dal database. Fai finta che tutto sia GET, e comportati di conseguenza legandoli come parametri.

Puoi anche disinfettare e limitare l'input (ad esempio permetti solo nomi utente alfanumerici) prima di essere archiviato nel database e dopo che è stato recuperato dal database. Ma non mi affiderei a questo come unica linea di difesa, quindi uso anche le query parametrizzate.

Qui non c'è nulla di "speciale". La cosiddetta iniezione SQL di "secondo ordine" è la stessa iniezione SQL con la minima differenza che il contenuto proviene dal database piuttosto che dai dati immessi direttamente dall'utente. Si applicano le stesse regole

• disinfetta sempre i dati di input indipendentemente da dove proviene (l'utente, un file, un database, ecc.)

• Non utilizzare mai concatenazioni di stringhe per creare comandi eseguibili. Utilizza le istruzioni preparate ecc.

La regola empirica è di non fidarsi mai di dati di input, indipendentemente da quanto pensi che possa essere sicuro. Non ci si può fidare di ciò che l'utente potrebbe inserire ed è necessario presumere che anche i propri archivi di dati (ad esempio il proprio database) potrebbero essere stati compromessi in qualche modo o avere "cattivi dati" in esso contenuti. Scrivi il tuo codice con il presupposto che tu stia correndo in un ambiente ostile come la realtà è, sei.

BTW Vedo che la documentazione di Oracle non è migliorata! Questo è un blurb molto mal scritto e mal spiegato per quanto riguarda l'iniezione di SQl.