Am I imune a injeções de SQL se eu usar procedimentos armazenados?

Question

Vamos dizer que no banco de dados MySQL (se importa).

Answer 1

Não, você não vai ser completamente seguro. Como já foi mencionado, consultas parametrizadas são sempre o caminho a percorrer - não importa como você está acessando o banco de dados

.

É um pouco de uma lenda urbana que, com procs você está seguro. Penso que a razão as pessoas estão sob essa ilusão é porque a maioria das pessoas assumem que você vai chamar os procs com consultas parametrizadas do seu código. Mas se você não fizer isso, se por exemplo você fazer algo como o abaixo, você está aberta:

SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();

Porque você está usando o conteúdo não filtrada do usuário final. Mais uma vez, todos eles têm de fazer é terminar a linha ( ";"), adicionar seus comandos perigosas, e boom - você está hosed.

(Como um aparte, se você está na web, não tome lixo não filtrada da string de consulta do navegador -. Que torna absurdamente fácil de fazer coisas extremamente ruins para seus dados)

Se você parametrizar as consultas, você está em muito melhor forma. No entanto, como outros aqui mencionados, se o seu proc ainda está gerando SQL dinâmica e execução que, ainda pode haver problemas.

Devo observar que eu não sou anti-proc. Procs pode ser muito útil para a resolução de certos problemas com acesso a dados. Mas procs são não uma "solução de bala de prata para injeções SQL.

Answer 2

Você só é imune a injeções de SQL se você consistenly usar consultas parametrizadas. Você é quase imune a injeções de SQL se você usar adequada escapar em toda parte (mas pode haver, e tem sido, erros nas rotinas escapando, por isso não é tão infalível como parâmetros).

Se você chamar um procedimento armazenado, acrescentando os argumentos por concatenação, ainda posso adicionar uma consulta aleatória no final de um dos campos de entrada - por exemplo, se você tem CHAMADA CheckLogin @username = '$ username', @ password = '$ password', com os $ -coisas representando variáveis ??diretamente concatenadas, nada me impede de mudar a variável $ senha para ler "'; DROP DATABASE; -".

Obviamente, se você limpar a entrada de antemão, isso também contribui para a prevenção de injeção SQL, mas isso pode potencialmente filtrar dados que não deveriam ter sido limpos.

Answer 3

Depende do que seus procedimentos armazenados fazer. Se eles gerar dinamicamente SQL com base em seus parâmetros e, em seguida, executar esse SQL, então você ainda está vulnerável. Caso contrário, você está muito mais propensos a ficar bem - mas hesito em soar 100% confiante

!

Answer 4

Não. Se você está construindo SQL que chama um procedimento armazenado você ainda é um alvo.

Você deve ser a criação de consultas parametized no lado do cliente.

Answer 5

Não, como você poderia ainda usar D-SQL em seus procedimentos armazenados ... e validação e restringindo sua entrada é uma boa idéia em qualquer caso.

Answer 6

Stored Procedures não são uma garantia, porque o que é realmente vulnerável é qualquer código dinâmico, e que inclui o código dentro de procedimentos armazenados e chamadas geradas dinamicamente para procedimentos armazenados.

consultas parametrizadas e procedimentos armazenados chamados com parâmetros são ambos invulnerável a injeção contanto que eles não usam entradas arbitrárias para gerar o código. Note-se que há uma abundância de código dinâmico que também não é vulnerável a injecção (por exemplo inteiro parâmetros em código dinâmico).

Os benefícios de uma grande parte (não tenho certeza 100% é realmente possível) armazenados procs baseada em arquitetura, no entanto, é que a injeção pode até mesmo ser um pouco defendida contra (mas não perfeitamente) para código dinâmico no lado do cliente, porque :

Somente permissões EXEC são concedidos a qualquer contexto de usuário do aplicativo está se conectando abaixo, portanto, qualquer SELECT, INSERT, UPDATE, consultas de exclusão será simplesmente falhar. Claro, GOTA etc não deve ser permitido qualquer maneira. Assim, qualquer injeção teria que ser na forma de EXEC, então, em última análise, apenas as operações que você definiu em sua camada de SP vai mesmo estar disponível (SQL não arbitrária) para injetar contra.

Entre os muitos outros benefícios de definir seus serviços de banco de dados como um conjunto de procedimentos armazenados (como qualquer camada de abstração de software) são a capacidade de refatorar seu debaixo de banco de dados sem aplicativos que afetam, a capacidade de entender melhor e monitorar os padrões de uso em seu banco de dados com um profiler, e a capacidade de otimizar seletivamente no banco de dados sem ter que implantar novos clientes.

Answer 7

Além disso, considere o uso de granulação fina acesso de dados, (também chamado geralmente Role Based Access Control) O principal utilizador do seu banco de dados deve ter exatamente as permissões necessárias para fazer o seu trabalho e nada mais. Não é necessário criar novas tabelas após a instalação? Revogar essa permissão. Não temos uma necessidade legítima para executar as sysdba? Então não! A injeção sorrateira instruindo o usuário a "DROP DATABASE" será bloqueado se o usuário não foi concedido essa permissão. Então tudo que você precisa se preocupar é de dados de vazamento de instruções SELECT.