Existe alguma maneira de injetar SQL mesmo se o caractere ' for excluído?

Question

Se de uma consulta SQL eu remover todos os caracteres ', existe alguma outra maneira de fazer um ataque de injeção SQL no banco de dados?

Como pode ser feito?Alguém pode me dar exemplos?

Answer 1

Sim existe.Um trecho de Wikipédia

"SELECT * FROM data WHERE id = " + a_variable + ";"

Fica claro nesta afirmação que o autor pretendia que a_variable fosse um número correlacionado ao campo "id".No entanto, se for de fato uma string, o usuário final poderá manipular a instrução como quiser, evitando assim a necessidade de caracteres de escape.Por exemplo, definir a_variable como

1;DROP TABLE users

irá eliminar (excluir) a tabela "users" do banco de dados, já que o SQL seria renderizado da seguinte forma:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

A injeção de SQL é não um ataque simples para lutar.Eu faria uma pesquisa muito cuidadosa se fosse você.

Answer 2

Sim, dependendo da declaração que você está usando.É melhor você se proteger usando procedimentos armazenados ou, pelo menos, consultas parametrizadas.

Ver WikiPédia para amostras de prevenção.

Answer 3

Sim, é definitivamente possível.

Se você tiver um formulário no qual espera que um número inteiro faça sua próxima instrução SELECT, poderá inserir algo semelhante:

SELECIONE DE thingy ONDE atributoID=

• 5 (boa resposta, sem problemas)
• 5;Tabela DROP users;(mau Mau Mau...)

O site a seguir detalha mais técnicas clássicas de injeção de SQL: Folha de dicas de injeção SQL.

Usar consultas parametrizadas ou procedimentos armazenados não é melhor.Estas são apenas consultas pré-fabricadas usando os parâmetros passados, que também podem ser fonte de injeção.Também está descrito nesta página: Atacando procedimentos armazenados em SQL.

Agora, se você suprimir a citação simples, evitará apenas um determinado conjunto de ataques.Mas nem todos eles.

Como sempre, não confie em dados vindos de fora.Filtre-os nestes 3 níveis:

• Nível de interface para coisas óbvias (uma lista de seleção suspensa é melhor que um campo de texto livre)
• Nível lógico para verificações relacionadas à natureza dos dados (int, string, comprimento), permissões (este tipo de dados pode ser utilizado por este usuário nesta página)...
• Nível de acesso ao banco de dados (escape de aspas simples...).

Divirta-se e não esqueça de conferir WikiPédia para obter respostas.

/Vei

Answer 4

Sugiro que você passe as variáveis ​​como parâmetros, e não construa seu próprio SQL.Caso contrário, sempre haverá uma maneira de fazer uma injeção de SQL, de maneiras que atualmente desconhecemos.

O código que você cria é algo como:

' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

Se você tem um nome como o meu com um ' nele.É muito irritante que todos os caracteres ' sejam removidos ou marcados como inválidos.

Você também pode querer dar uma olhada nisso Pergunta Stackoverflow sobre injeções SQL.

Answer 5

SQL embutido parametrizado ou procedimentos armazenados parametrizados são a melhor maneira de se proteger.Como outros apontaram, simplesmente remover/escapar o caractere de aspas simples não é suficiente.

Você notará que falo especificamente sobre procedimentos armazenados "parametrizados".Simplesmente usar um procedimento armazenado também não será suficiente se você voltar a concatenar os parâmetros passados ​​do procedimento.Em outras palavras, agrupar exatamente a mesma instrução SQL vulnerável em um procedimento armazenado não o torna mais seguro.Você precisa usar parâmetros em seu procedimento armazenado, assim como faria com SQL embutido.

Answer 6

Além disso, mesmo que você apenas procure o apóstrofo, não deseja removê-lo.Você quer escapar isto.Você faz isso substituindo cada apóstrofo por dois apóstrofos.

Mas consultas/procedimentos armazenados parametrizados são muito melhores.

Answer 7

Como esta é uma pergunta relativamente antiga, não me preocuparei em escrever uma resposta completa e abrangente, já que a maioria dos aspectos dessa resposta foram mencionados aqui por um autor ou outro.
Acho necessário, entretanto, trazer à tona outra questão que não foi abordada por ninguém aqui - Contrabando de SQL.Em certas situações, é possível "contrabandear" o caractere de aspas ' para sua consulta mesmo se você tentou removê-lo.Na verdade, isso pode ser possível mesmo se você usar comandos, parâmetros, procedimentos armazenados etc.

Confira o artigo completo da pesquisa em http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (divulgação, eu fui o principal pesquisador sobre isso) ou apenas pesquise no Google "SQL Smuggling".

Answer 8

...uh, cerca de 5.000.000 de outras maneiras

talvez algo como 5; drop table employees; --

o sql resultante pode ser algo como:select * from somewhere where number = 5; drop table employees; -- and sadfsf

(-- inicia um comentário)

Answer 9

Sim absolutamente:dependendo do seu dialeto SQL e outros, há muitas maneiras de obter injeção que não usam apóstrofo.

A única defesa confiável contra ataques de injeção SQL é usar o suporte para instruções SQL parametrizadas oferecido pela interface do seu banco de dados.

Answer 10

Em vez de tentar descobrir quais caracteres filtrar, eu me limitaria a consultas parametrizadas e removeria totalmente o problema.

Answer 11

Depende de como você monta a consulta, mas em essência sim.

Por exemplo, em Java, se você fizesse isso (exemplo deliberadamente flagrante):

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

então há uma boa chance de você estar se abrindo para um ataque de injeção.

Java tem algumas ferramentas úteis para se proteger contra isso, como PreparedStatements (onde você passa uma string como "SELECT name_ from Customer WHERE ID = ?" e a camada JDBC lida com escapes enquanto substitui o ?tokens para você), mas algumas outras linguagens não são tão úteis para isso.

Answer 12

A coisa é a entrada talvez genuína do apóstrofo e você precisa escapar deles duplicando-os quando estiver usando SQL embutido em seu código.O que você está procurando é um padrão regex como:

\;.*--\

Um ponto e vírgula usado para encerrar prematuramente a instrução genuína, alguns SQL injetados seguidos por um hífen duplo para comentar o SQL final da instrução genuína original.Os hífens podem ser omitidos no ataque.

Portanto a resposta é:Não, simplesmente remover apóstrofos não garante segurança contra SQL Injection.

Answer 13

Só posso repetir o que outros disseram.SQL parametrizado é o caminho a percorrer.Claro, é um pouco chato codificá-lo - mas depois de fazer isso uma vez, não é difícil recortar e colar esse código e fazer as modificações necessárias.Temos muitos aplicativos .Net que permitem aos visitantes do site especificar uma ampla gama de critérios de pesquisa, e o código cria a instrução SQL Select dinamicamente - mas tudo o que poderia ter sido inserido por um usuário vai para um parâmetro.

Answer 14

Quando você espera um parâmetro numérico, você deve sempre validar a entrada para ter certeza de que é numérico.Além de ajudar na proteção contra injeção, a etapa de validação tornará o aplicativo mais amigável.

Se você receber id = "hello" quando esperava id = 1044, é sempre melhor retornar um erro útil ao usuário em vez de deixar o banco de dados retornar um erro.