No Postgres, as consultas preparadas e as funções definidas pelo usuário são equivalentes a um mecanismo de proteção contra injeção de SQL ?
Existem vantagens particulares em uma abordagem sobre a outra?
AskOverflow.Dev
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 - contanto que você não chame funções não seguras do corpo e passe parâmetros.
Funções PL/pgSQL
Com
LANGUAGE plpgsql, a resposta normalmente é sim .No entanto , PL/pgSQL permite SQL dinâmico onde os parâmetros passados (ou partes) são concatenados a uma string de consulta e executados com
EXECUTE. Isso pode converter a entrada do usuário em código SQL e possibilitar a injeção de SQL. As ferramentas estão lá para fazê-lo com segurança. Você não pode dizer de fora se o corpo da função lida com isso corretamente, você tem que olhar para o código.Instruções SQL simples usando parâmetros como valores são seguras contra injeção SQL, assim como as funções SQL. Use SQL dinâmico somente quando necessário e siga estas 4 diretrizes:
De preferência, passe valores como valores com a
USINGcláusula. Torna a injeção de SQL impossível no principal. Exemplo .Se você concatenar valores na string SQL, use:
format()com especificador de formato%L. Exemplo .quote_literal()ouquote_nullable(). Exemplo .Envolve 'strings' em aspas simples com segurança, evitando assim erros de sintaxe e injeção de SQL.
Parâmetros de processo que devem ser tratados como identificadores na string SQL com:
format()com especificador de formato%I. Exemplo .quote_ident(). Exemplo .regclasspara nomes de tabela:_tbl::regclass. (Só funciona para objetos existentes !) Exemplo .Coloca "identificadores" entre aspas duplas com segurança quando necessário , evitando assim erros de sintaxe e injeção de SQL.
Relacionado:
Nunca apenas construa uma string a partir da entrada do usuário e execute. Isso inclui identificadores, passados diretamente por um usuário ou obtidos de um catálogo do sistema. Tudo tem que ser tratado como entrada do usuário e citado apropriadamente ao construir SQL dinâmico!
Mais sobre as implicações de desempenho nesta resposta relacionada:
Noções básicas sobre injeção de SQL:
Considerações semelhantes se aplicam a outras linguagens do lado do servidor que permitem SQL dinâmico.