Como posso evitar ataques de injeção SQL?

Question

Ontem eu estava falando com um desenvolvedor, e ele mencionou algo sobre como restringir as inserções no campo de banco de dados, como, cordas, como -- (minus).

Ao mesmo tipo, o que eu sei é que é uma boa abordagem para escapar caracteres HTML como <, > etc. Não --. Isso é verdade? Eu tenho que preocupar com --, ++? É mais como um mito ou material antigo?

---

Atualização

Muito obrigado por todas as respostas, é fácil entender como isso desde que eu sou uma espécie de novo para tudo isso. Bem, para ser mais específico, neste caso, a nossa discussão foi sobre eo site C # ASP.NET MVC que estamos desenvolvendo, por isso há uma forma de conta aberta complexo lá com informações importantes, então eu não tenho certeza se MVC usando o Linq para interface com a base de dados já vem com esse tipo de proteção ou não. Então, se alguém poderia fornece algumas dicas sobre isso, seria ótimo. Obrigado novamente

Answer 1

A maneira correta de ataques de injeção evitar SQL não é a determinados personagens problemáticos simplesmente Desautorizar, mas em vez de usar SQL parametrizado. Em suma, parametrizado SQL impede que o banco de dados de execução de entrada do usuário crus como parte do comando SQL este entrada do usuário impede tipo "drop table" de ser executado. Apenas escapar caracteres não pára todas as formas de ataques de injeção SQL e excluindo certas palavras como "Drop" não funciona em todos os casos; não pode haver certos campos onde "Drop" é uma parte perfeitamente válido da entrada de dados.

Você pode encontrar alguns bons artigos sobre o tema do SQL paramaterized aqui:

https: //blog.codinghorror. com / give-me-parametrizado-sql-ou-dá-me-death /

http://www.codeproject.com/KB/database/ParameterizingAdHocSQL.aspx

Agora que você mencionou que você está trabalhando com ASP.net posso dar-lhe alguns links que tratam especificamente de injeção SQL em ASP.

https://dzone.com/articles/aspnet-preventing-sql-injectio http://www.codeproject.com/KB/aspnet/SQL_Injection_. aspx? msg = 3209511

Aqui está um artigo mais geral em fazer o seu ASP mais seguro: http://www.codeproject.com/KB/web-security/Securing_ASP_NET_Apps. aspx

E, claro, o artigo do MSDN sobre a injeção de SQL: http://msdn.microsoft.com/en-us/library/ms998271. aspx

Answer 2

A injeção SQL é um risco de segurança elevado para a maioria dos sites que permitem aos usuários parâmetros de esguicho em uma indicação de que é executado em um banco de dados.

Um exemplo simples seria:

Campo de entrada "Nome: _________

"SELECT * FROM tblCustomer WHERE Name = '" + nameInputField + "'"

Então, se eu digitar "Bob" nós temos

"SELECT * FROM tblCustomer WHERE Name = 'Bob'"

Mas se eu digitar "'; DROP TABLE tblCustomer", vamos acabar com o bem mais sinistro

"SELECT * FROM tblCustomer WHERE Name = ''; DROP TABLE tblCustomer"

Existem muitas maneiras de evitar esses problemas, e muitos são construídos em qualquer linguagem que você está usando - por isso, em vez de pensar em todas as possibilidades desonestos ";", "-", "/ *" etc, e tentar Use algo que já existe.

Grito para fora o idioma que você está usando e eu tenho certeza que podemos dizer-lhe como evitar esses ataques.

Answer 3

Ele estava falando sobre ataques SQL Injection , como é bastante razão no que disse.

O problema não é com esses dados existentes no banco de dados, mas em passar dados de entrada diretamente para o banco de dados sem saneantes-lo.

Sem limpá-lo, se alguém passa em uma corda terminando com um ; eles podem depois segui-lo com qualquer coisa que eles querem (select * from sys.objects, por exemplo) ou algo mais malicioso, como deixar cair algumas tabelas.

É difícil proteger contra totalmente, mas se você usar uma boa biblioteca DB do seu código e siga as práticas conhecidas, tais como a utilização de consultas paremeterized você limitar o dano possível.

loja como muitos -- em seu banco de dados como você quer, mas não passe que através de seu banco de dados sem passar por um processo de limpeza (isto é onde uma biblioteca boa DB é vital - que deveria citações de limpeza e outra entrada potencialmente prejudiciais) .

Answer 4

Não há nada de "perigoso" sobre como inserir uma string contendo -- em um banco de dados.

É perigoso para inserir qualquer em uma tabela de banco de dados que vem diretamente da entrada do usuário sem processá-lo, caso contrário, você se mantém aberto para ataques de injeção SQL . Exemplo: Um codificador permite que o usuário digite seu nome em um campo, e os tipos de usuários:

Joe '); drop table users; commit transaction; --

e, em seguida, as coloca codificador que em seu banco de dados MySQL assim:

conn.execute("insert into users (username) values ('" + userInput + "')");

lança O usuário excluiu a tabela de usuários (assumindo que o login do banco de dados tinha direito de fazer isso, o que não deveria - mas isso é um tópico diferente), porque o codificador não garantiu que a cadeia do usuário foi escapado corretamente, e assim ele foi enviado diretamente para o motor DB e o atacante tem uma boa risada. : -)

Use quaisquer ferramentas seu ambiente oferece para garantir que as cordas são escapou corretamente. Por exemplo, JDBC usa a classe PreparedStatement para isso. A maioria dos ambientes terá algo similar.

Answer 5

Use parametrizado consultas. Essas consultas representam as variáveis ??como um espaço reservado no SQL, tais como select * from person where name = ?. Depois de criar a consulta SQL, você definir os valores dos parâmetros na consulta. consultas parametrizadas garantir que tudo o que foi substituído pelo marcador de posição não será considerado como parte da instrução SQL.

artigo Veja Jeff Atwood para uma boa síntese de consultas parametrizadas.

Answer 6

Não é perigoso, enquanto você escapar corretamente os dados ao fazer INSERT / UPDATE /...

E escapar caracteres HTML é não uma abordagem boa. Imagine que você escreveu uma função que escapa tais personagens e você armazenou algum texto escapou no banco de dados. Então você percebe que a sua função não escapou '<', assim você alterar a função ... agora o que acontece com os registros que já estão no banco de dados? - Seus personagens '<' vai ficar unescaped. Assim, NUNCA fuga texto antes de armazená-lo no banco de dados (escapar a consulta SQL, é claro). Escapando deve acontecer quando o HTML / XML / ... página é produzida fora do texto, isto é, depois de consultar o texto original do banco de dados!