+2

Anti SQL Injection

criado por Herbert Araujo em 11/12/2003 11:01pm
Função que protege o seu site de SQL Injection e de caracteres inválidos. Você pode acrescentar novas palavras ou caracteres conforme a sua necessidade. Expliquei o funcionamento desse script no artigo "Anti SQL Injection" aqui mesmo no phpBrasil.
Data Autor Changelog Download
11/12/2003 11:01pm Herbert Araujo - Versão 1.0
22/11/2004 11:37am Gustavo C. da Costa Versão 1.1 Versão 1.1
26/01/2006 6:36pm Lauro Assis Lima de Brito Versão 1.11 Versão 1.11
27/01/2006 6:43pm Lauro Assis Lima de Brito Versão 1,0 Versão 1,0

Comentários:

Mostrando 1 - 8 de 8 comentários
Gente, seria mais seguro utilizar expressão regular para detectar a injeção? Nos formularios de Login.

Recentemente peguei um site para reconfigurar no servidor, e esse site estava com várias falhas na programação, inclusive tinha vírus. Porvavelmente eles virus foram gravados nos arquivos php em forma de iframes, que chamava uma página com virus, logo abaixo de uma include.


Alguém tem idéia de como fazer segurança nesse sentido? os arquivos incluidos não vem do GET
tipo

include("pasta/".$_GET['pagina']);


Usei expressões regulares para validar as variáveis vindas do GET e também usei expressões regulares para validar os Formularios.
15/12/2008 11:18am (~15 anos atrás)

Eu passei o controle pra duas funções e criei um base de dados com as sequencias e palavras reservadas do sql. Acho que poderia ser filtrado na tabela ainda. mas foi um passo pra aprimorarmos a nossa defesa.
27/01/2006 6:46pm (~18 anos atrás)

Lauro, muito interessante essas 23 palavras adicionadas! Valeu.
27/01/2006 10:11am (~18 anos atrás)

incorporei estas 23 palavras no script e forcei a entrada para caixa baixa pra não ficar repetindo as mesmas palavras.

O script está funcionando perfeitamente a conforme forem surgindo mais palavras bastará criarmos novos arrays.

Eu tentei utilizar o sistema de guardar ID dos forms em sessions para verificação posterior mas comecei a ter problemas. Tive vários relatos de usuários que não conseguiam se logar ou se cadastrar pois por alguma razão, o ID do form não batia com o ID da session e o script fazia o die informando a tentativa de invasão, o que não era verdade. Teoricamente isso deveria funcionar sem problemas e seria uma segurança simples mas eficaz, já que os javascript não deixariam entrar codigos maliciosos nos forms, o usuario teria que salvar os forms e submetê-los offline.
26/01/2006 6:41pm (~18 anos atrás)

Eu garimpando pelo google, encontrei 23 palavras utilizadas neste tipo de ataque e incorporei no script.
26/01/2006 6:34pm (~18 anos atrás)

Gostaria de propor uma mudança nesse script:

if($txt){
if(validatxt(STRTOLOWER($txt))){
echo("caracteres ou palavra inválida");
}else{
echo("ok!");
}
}

Se o cara entrar com o comando SQL em MAIÚSCULO ele vai conseguir entrar.
22/11/2004 11:28am (~19 anos atrás)

Realmente eu tive um problema no mês passado e graças a Locaweb eu consegui restaurar a minha base de dados. Criei vários scripts de validação para barrar esse tipo de ataque e um deles foi colocar um script de validação em javascript nos forms de cadastros com um diferencial. Antes de montar o form, o sistema gera um número de ID randomico com 10 digitos e coloca como hidden e salva em session. Quando o form é submetido, essa chave e comparada e caso sejam diferentes, o script é imediatamente encerrado. Note que como o javascript vai brecar todo caractere inválido, o invasor teria que salvar a pagina do form, alterar e tentar fazer o submit off-line, assim o Id salvo em session na hora da geração do form jamais vai se repetir e portanto o form vai ser desconsiderado. Essa técnica também foi utilizada nos forms de login onde o javascript so aceita caracteres a..z e 0..9.

Valeu
25/02/2004 7:59pm (~20 anos atrás)

marco antonio disse:
Gosttei muito da contribuição.
Valeu!!
14/12/2003 6:16pm (~20 anos atrás)

Novo Comentário:

(Você pode usar tags como <b>, <i> ou <code>. URLs serão convertidas para links automaticamente.)