Sono immune alle iniezioni di SQL se utilizzo le procedure memorizzate?

Question

Diciamo sul database MySQL (se è importante).

Answer 1

No, non sarai completamente al sicuro. Come altri hanno già detto, le query con parametri sono sempre la strada da percorrere, indipendentemente da come si accede al database.

È un po 'una leggenda urbana che con i procs sei al sicuro. Penso che il motivo per cui le persone sono sotto questa illusione è perché la maggior parte delle persone presume che chiamerai procs con query parametrizzate dal tuo codice. Ma se non lo fai, se per esempio fai qualcosa come il seguente, sei spalancato:

SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();

Perché stai utilizzando contenuti non filtrati dall'utente finale. Ancora una volta, tutto ciò che devono fare è terminare la linea ("quot";), aggiungere i loro comandi pericolosi e boom.

(A parte questo, se sei sul Web, non prendere spazzatura non filtrata dalla stringa di query del browser, il che rende assurdamente facile fare cose estremamente brutte ai tuoi dati.)

Se si parametrizzano le query, si è in una forma molto migliore. Tuttavia, come altri hanno già detto, se il tuo proc sta ancora generando SQL dinamico ed eseguendolo, potrebbero esserci ancora problemi.

Dovrei notare che non sono anti-proc. Procs può essere molto utile per risolvere alcuni problemi con l'accesso ai dati. Ma i proc sono non una soluzione di "proiettile d'argento" alle iniezioni di SQL.

Answer 2

Sei immune alle iniezioni di SQL solo se usi costantemente query con parametri. Sei quasi immune alle iniezioni di SQL se usi la fuga corretta ovunque (ma ci possono essere, ed è stato, bug nelle routine di fuga, quindi non è infallibile come i parametri).

Se chiami una procedura memorizzata, aggiungendo gli argomenti per concatenazione, posso ancora aggiungere una query casuale alla fine di uno dei campi di input - ad esempio, se hai CALL CheckLogin @username = '$ username', @ password = '$ password', con $ -things che rappresentano variabili direttamente concatenate, nulla mi impedisce di cambiare la variabile $ password in read " '; DROP DATABASE; - ".

Ovviamente, se si pulisce in anticipo l'input, ciò contribuisce anche a prevenire l'iniezione di SQL, ma ciò può potenzialmente filtrare i dati che non avrebbero dovuto essere puliti.

Answer 3

Dipende da cosa fanno i tuoi proc memorizzati. Se generano dinamicamente SQL in base ai loro parametri e quindi eseguono tale SQL, allora sei ancora vulnerabile. Altrimenti, è molto più probabile che tu stia bene, ma esito a sembrare sicuro al 100%!

Answer 4

no. Se stai costruendo SQL che invoca una stored procedure, sei ancora un obiettivo.

Dovresti creare query parametrizzate sul lato client.

Answer 5

No, dato che è ancora possibile utilizzare D-SQL nelle procedure memorizzate ... e la convalida e la limitazione dell'input è comunque una buona idea.

Answer 6

Le Stored procedure non sono una garanzia, perché ciò che è effettivamente vulnerabile è qualsiasi codice dinamico e che include il codice all'interno delle stored procedure e le chiamate generate dinamicamente alle stored procedure.

Le query con parametri e i processi memorizzati chiamati con parametri sono entrambi invulnerabili all'iniezione purché non utilizzino input arbitrari per generare codice. Si noti che esiste un sacco di codice dinamico che non è anche vulnerabile all'iniezione (ad esempio parametri interi nel codice dinamico).

I vantaggi di un'architettura basata su procs in gran parte (non sono sicuro che il 100% sia davvero possibile), tuttavia, è che l'iniezione può persino essere leggermente difesa (ma non perfettamente) per il codice dinamico sul lato client perché :

Solo le autorizzazioni EXEC sono concesse a qualsiasi contesto utente a cui l'app si sta connettendo, quindi qualsiasi query SELECT, INSERT, UPDATE, DELETE semplicemente fallirà. Naturalmente, DROP ecc. Non dovrebbe essere consentito comunque. Quindi qualsiasi iniezione dovrebbe essere sotto forma di EXEC, quindi alla fine saranno disponibili solo le operazioni che hai definito nel tuo livello SP (non SQL arbitrario) da iniettare.

Tra i molti altri vantaggi della definizione dei servizi di database come un insieme di procedure memorizzate (come qualsiasi livello di astrazione nel software) vi sono la capacità di riformattare il database sottostante senza influire sulle app, la capacità di comprendere e monitorare meglio i modelli di utilizzo in il tuo database con un profiler e la possibilità di ottimizzare selettivamente all'interno del database senza dover distribuire nuovi client.

Answer 7

Inoltre, considera l'utilizzo dell'accesso al database a grana fine, (chiamato anche generalmente controllo dell'accesso basato sui ruoli) L'utente principale del tuo database dovrebbe avere esattamente le autorizzazioni necessarie per fare il suo lavoro e nient'altro. Non è necessario creare nuove tabelle dopo l'installazione? Revocare tale autorizzazione. Non hai un legittimo bisogno di correre come sysdba? Allora no! Un'iniezione subdola che istruisce l'utente a "DROP DATABASE" verrà ostacolato se l'utente non ha ottenuto tale autorizzazione. Quindi tutto ciò di cui devi preoccuparti sono le istruzioni SELECT che perdono dati.