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

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

Ç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 des valeurs et l'injection SQL n'est pas possible - tant que vous n'appelez pas de fonctions dangereuses à partir du corps et passez des paramètres.

Fonctions PL / pgSQL

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

Cependant , PL / pgSQL permet un SQL dynamique où les paramètres (ou parties) passés sont concaténés à une chaîne de requête et exécutés 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 le SQL dynamique , passez de préférence des valeurs en tant que valeurs avec:

• la USINGclause. Exemple .

Rend l'injection SQL impossible sur le principal.

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

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

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

Traitez les paramètres qui doivent être traités comme des identifiants dans la chaîne SQL avec:

• format()avec spécificateur de format%I . Exemple .
• quote_ident(). Exemple .
• un casting à un type enregistré - regclasspour les noms de table: _tbl::regclass. Exemple .

Inclut les chaînes entre guillemets en toute sécurité là où cela est nécessaire , évitant ainsi les erreurs de syntaxe et l'injection SQL.

En relation:

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

Ne construisez jamais une chaîne à partir de l'entrée utilisateur et exécutez-la. 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.