Captura de injeção SQL e outras solicitações da Web maliciosos

votos
17

Eu estou procurando uma ferramenta que pode detectar solicitações maliciosas (como injeção de SQL óbvio obtém ou posts) e vai proibir imediatamente o endereço IP do solicitante / adicionar a uma lista negra. Estou ciente de que em um mundo ideal o nosso código deve ser capaz de lidar com tais pedidos e tratá-los adequadamente, mas há um monte de valor de tal ferramenta, mesmo quando o site é protegido contra estes tipos de ataques, uma vez que pode levar a poupar largura de banda, impedindo inchaço da análise, etc.

Idealmente, eu estou procurando um cross-platform ( LAMP/.NETsolução) que fica em um nível mais elevado do que a pilha de tecnologia; talvez no nível do hardware web-servidor ou. Eu não tenho certeza se isso existe, no entanto.

De qualquer forma, eu gostaria de ouvir o feedback da comunidade para que eu possa ver o que as minhas opções pode ser em relação a implementação e abordagem.

Publicado 04/08/2008 em 15:40
fonte usuário
Em outras línguas...                            


8 respostas

votos
10

Seu quase olhando para o caminho errado, nenhuma ferramenta 3party que não tem conhecimento de sua métodos de aplicação / nomeação / data / domínio está indo vai ser capaz de protegê-lo perfeitamente.

Algo como a prevenção de injeção SQL é algo que tem que ser no código, e melhor escrita pelas pessoas que escreveram o SQL, porque eles são os que vão saber o que deve / não deve ser nesses campos (a menos que seu projeto tem muito boas docs )

Seu direito, tudo isso já foi feito antes. Você não consegue ter que reinventar a roda, mas você tem que esculpir uma nova causa de diferenças nos diâmetros de eixo de todos.

Este não é um drop-in e problema correr, você realmente tem que estar familiarizado com o que a injeção exatamente SQL é antes que você possa evitá-lo. É um problema sorrateira, por isso leva proteções igualmente sorrateiras.

Estes 2 links me ensinou muito mais do que o básico sobre o assunto para começar, e me ajudou a melhor frase minhas futuras pesquisas sobre questões específicas que não foram respondidas.

E enquanto este is not bastante um localizador de 100%, ele vai "mostrar-lhe a luz" no problema em seu código existente existente, mas como com webstandards, não pare de codificação, uma vez que você passar este teste.

Respondeu 04/08/2008 em 16:43
fonte usuário

votos
5

O problema com uma ferramenta genérica é que é muito difícil chegar a um conjunto de regras que só irá corresponder contra um ataque genuíno.

palavras-chave SQL são todas as palavras em inglês, e não se esqueça de que a cadeia

 DROP TABLE users;

é perfeitamente válido em um campo de formulário que, por exemplo, contém uma resposta a uma questão de programação.

A única opção sensata é higienizar a entrada antes mesmo passá-lo para seu banco de dados, mas passá-lo, no entanto. Caso contrário, muitos usuários perfeitamente normais, não maliciosos vão ser banido do seu site.

Respondeu 04/08/2008 em 16:11
fonte usuário

votos
3

A Oracle tem um tutorial online sobre SQL Injection . Mesmo que você quer uma solução pronta, isso pode dar-lhe algumas dicas sobre como usá-lo melhor para se defender.

Respondeu 05/08/2008 em 18:38
fonte usuário

votos
3

Uma pequena coisa para manter em mente: Em alguns países (ou seja, a maioria da Europa), as pessoas não têm endereços IP estáticos, de modo lista negra não deve ser para sempre.

Respondeu 04/08/2008 em 16:22
fonte usuário

votos
3

Um método que pode funcionar para alguns casos seria a de tomar a string SQL que seria executado se você usou ingenuamente os dados do formulário e passá-lo para algum código que conta o número de declarações que seria realmente ser executadas. Se for maior do que o número esperado, então há uma boa chance de que uma injeção foi tentada, especialmente para campos que não são susceptíveis de incluir caracteres de controle, tais como nome de usuário.

Algo como uma caixa de texto normal seria um pouco mais difícil uma vez que este método seria muito mais propensos a voltar falsos positivos, mas isso seria um começo, pelo menos.

Respondeu 04/08/2008 em 16:20
fonte usuário

votos
0

Interessante como esta está a ser implementado anos mais tarde pelo Google e eles remover o URL todos juntos, a fim de evitar ataques XSS e outros acitivites maliciosos

Respondeu 24/07/2014 em 06:18
fonte usuário

votos
0

Um dos meus sites foi recentemente cortado por meio de injeção SQL. Ele adicionou um link para um vírus para cada campo de texto no db! A correção foi adicionar algum código em busca de palavras-chave SQL. Felizmente, eu desenvolvi em ColdFiusion, para que o código se senta no meu arquivo Application.cfm que é executado no início de cada página e ele olha para todas as variáveis ​​de URL. Wikipedia tem alguns bons links para ajudar também.

Respondeu 16/09/2008 em 15:04
fonte usuário

votos
0

Agora que penso nisso, um filtro Bayesian semelhante aos usados ​​para bloquear o spam pode funcionar decentemente também. Se você reuniu um conjunto de texto normal para cada campo e um conjunto de injeções de SQL, você pode ser capaz de treiná-lo para ataques de injeção de bandeira.

Respondeu 04/08/2008 em 16:26
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more