Injection SQL dans les fonctions Postgres vs requêtes préparées

Question

Dans Postgres, les requêtes préparées et les fonctions définies par l'utilisateur sont-elles équivalentes à mécanisme de protection contre l'injection SQL?
Y a-t-il des avantages particuliers dans une approche par rapport à l'autre?

Answer 1

Ça dépend.

Fonctions SQL

Avec LANGUAGE sql , la réponse est généralement oui .

Les paramètres passés sont traités comme valeurs et l'injection SQL n'est pas possible - tant que vous n'appelez pas de fonctions dangereuses du corps et passez les paramètres.

Fonctions PL/pgSQL

Avec LANGUAGE plpgsql , la réponse est normalement oui .

Cependant , PL/pgSQL permet SQL dynamique où les paramètres passés (ou parties) sont concaténées à une chaîne de requête et exécutées avec EXECUTE. Cela peut convertir les entrées utilisateur en code SQL et rendre l'injection SQL possible. Vous ne pouvez pas dire de l'extérieur si le corps de la fonction la gère correctement. Des outils sont fournis.

Utilisez uniquement le SQL dynamique là où vous en avez besoin. Les instructions SQL simples utilisant des paramètres comme valeurs sont sûres contre l'injection SQL comme les fonctions SQL.

Pour SQL dynamique , passez de préférence valeurs comme valeurs avec:

• la clause USING. Exemple .

Rend l'injection SQL impossible sur le principal.

Si vous concaténez valeurs dans la chaîne SQL, utilisez:

• format() avec spécificateur de format %L . Exemple .
• quote_literal() ou quote_nullable() . Exemple .

Enveloppe les chaînes entre guillemets simples en toute sécurité, évitant ainsi les erreurs de syntaxe et l'injection SQL.

Paramètres de processus qui doivent être traités comme identificateurs dans la chaîne SQL avec:

• format() avec spécificateur de format %I . Exemple .
• quote_ident() . Exemple .
• a transtypé en un type enregistré - regclass pour les noms de table: _tbl::regclass. Exemple .

Inclut les chaînes entre guillemets doubles en toute sécurité si nécessaire, évitant ainsi les erreurs de syntaxe et l'injection SQL.

En relation:

• Refactoriser une fonction PL/pgSQL pour retourner la sortie de diverses requêtes SELECT
• Définir les noms de table et de colonne comme arguments dans une fonction plpgsql?

Jamais il suffit de construire une chaîne à partir de l'entrée utilisateur et de l'exécuter. Cela inclut les identifiants, transmis directement par un utilisateur ou récupérés à partir d'un catalogue système. Tous doivent être traités comme des entrées utilisateur et cités en toute sécurité lors de la construction de SQL dynamique!

En savoir plus sur les implications en termes de performances dans cette réponse connexe:

• Performance de la fonction

Notions de base sur l'injection SQL:

• http://bobby-tables.com/

Des considérations similaires s'appliquent aux autres langages côté serveur qui autorisent le SQL dynamique.