Iniezione SQL nelle funzioni Postgres vs query preparate

In Postgres, le query preparate e le funzioni definite dall'utente equivalgono a un meccanismo di protezione contro l'iniezione SQL ?
Ci sono vantaggi particolari in un approccio rispetto all'altro?

Dipende.

Funzioni SQL

Con LANGUAGE sql, la risposta è generalmente sì .

I parametri passati vengono trattati come valori e l'iniezione SQL non è possibile - purché non si chiamino funzioni non sicure dal corpo e si passino i parametri.

Funzioni PL / pgSQL

Con LANGUAGE plpgsql, la risposta è normalmente sì .

Tuttavia , PL / pgSQL consente SQL dinamico in cui i parametri (o parti) passati vengono concatenati a una stringa di query ed eseguiti con EXECUTE. Questo può convertire l'input dell'utente in codice SQL e rendere possibile l' iniezione SQL . Dall'esterno non si può dire se il corpo della funzione lo gestisce correttamente. Gli strumenti sono forniti.

Utilizzare SQL dinamico solo dove serve. Le semplici istruzioni SQL che utilizzano i parametri come valori sono sicure contro l'iniezione SQL come le funzioni SQL.

Per SQL dinamico , passare preferibilmente valori come valori con:

• la USINGclausola. Esempio .

Rende impossibile l'iniezione SQL in linea di principio.

Se si concatenano valori nella stringa SQL, utilizzare:

• format()con identificatore di formato%L . Esempio .
• quote_literal()oppurequote_nullable() . Esempio .

Avvolge le stringhe tra virgolette singole in modo sicuro, evitando così errori di sintassi e iniezione SQL.

Parametri di processo che devono essere trattati come identificatori nella stringa SQL con:

• format()con identificatore di formato%I . Esempio .
• quote_ident(). Esempio .
• un getto a un tipo registrato - regclassper i nomi di tabella: _tbl::regclass. Esempio .

Racchiude le stringhe tra virgolette in modo sicuro dove richiesto , evitando così errori di sintassi e iniezione SQL.

Relazionato:

• Rifattorizzare una funzione PL / pgSQL per restituire l'output di varie query SELECT
• Definire i nomi di tabelle e colonne come argomenti in una funzione plpgsql?

Non creare mai una stringa dall'input dell'utente ed eseguirla. Ciò include identificatori, passati direttamente da un utente o recuperati da un catalogo di sistema. Tutti devono essere trattati come input dell'utente e quotati in modo sicuro durante la creazione di SQL dinamico!

Ulteriori informazioni sulle implicazioni delle prestazioni in questa risposta correlata:

• Performance delle funzioni

Nozioni di base su SQL-injection:

• http://bobby-tables.com/

Considerazioni simili si applicano ad altri linguaggi lato server che consentono SQL dinamico.