Injeção de SQL nas funções do Postgres x consultas preparadas

No Postgres, as consultas preparadas e as funções definidas pelo usuário são equivalentes como um mecanismo de proteção contra a injeção de SQL ?
Existem vantagens particulares em uma abordagem em relação à outra?

Depende.

Funções SQL

Com LANGUAGE sql, a resposta é geralmente sim .

Os parâmetros passados ​​são tratados como valores e a injeção de SQL não é possível - desde que você não chame funções inseguras do corpo e passe parâmetros.

Funções PL / pgSQL

Com LANGUAGE plpgsql, a resposta é normalmente sim .

No entanto , o PL / pgSQL permite SQL dinâmico, onde parâmetros (ou partes) passados ​​são concatenados em uma sequência de consultas e executados com EXECUTE. Esta pode converter a entrada do usuário para o código SQL e faz a injeção de SQL possível . Você não pode dizer de fora se o corpo da função lida com isso adequadamente. Ferramentas são fornecidas.

Use apenas SQL dinâmico onde for necessário. Instruções SQL simples usando parâmetros como valores são seguras contra injeção de SQL, como funções SQL.

Para SQL dinâmico , passe preferencialmente valores como valores com:

• a USINGcláusula. Exemplo .

Torna a injeção de SQL impossível no principal.

Se você concatenar valores na cadeia SQL, use:

• format()com especificador de formato%L . Exemplo .
• quote_literal()ouquote_nullable() . Exemplo .

Agrupa seqüências de caracteres entre aspas simples com segurança, evitando erros de sintaxe e injeção de SQL.

Parâmetros do processo que devem ser tratados como identificadores na cadeia SQL com:

• format()com especificador de formato%I . Exemplo .
• quote_ident(). Exemplo .
• um elenco para um tipo registrada - regclasspara nomes de tabela: _tbl::regclass. Exemplo .

Inclui seqüências de caracteres entre aspas duplas com segurança quando necessário , evitando erros de sintaxe e injeção de SQL.

Relacionado:

• Refatorar uma função PL / pgSQL para retornar a saída de várias consultas SELECT
• Definir nomes de tabelas e colunas como argumentos em uma função plpgsql?

Nunca apenas crie uma string a partir da entrada do usuário e execute. Isso inclui identificadores, passados ​​diretamente por um usuário ou buscados em um catálogo do sistema. Tudo tem que ser tratado como entrada do usuário e citado com segurança ao criar SQL dinâmico!

Mais sobre implicações de desempenho nesta resposta relacionada:

• Função Desempenho

Noções básicas sobre injeção de SQL:

• http://bobby-tables.com/

Considerações semelhantes se aplicam a outras linguagens do servidor que permitem SQL dinâmico.