Como evitar um ataque de banco via campos de formulário?
Por exemplo, se num campo de formulário um engraçadinho taca algo do tipo "; drop table xxxxx;".
Existe algo já pronto a respeito? Se não, o que se costuma fazer?
Existe algo já pronto a respeito? Se não, o que se costuma fazer?
comentários (0)
suspender
Lista de Respostas:
05/11/2002 11:58am
(~22 anos atrás)
(~22 anos atrás)
Olha, acho que esse tipo de ataque não existe.
Qdo vc vai adicionar dados no mySQL por exemplo, vc usaria por exemplo:
INSERT INTO tabela ('nome', 'email', 'telefone') VALUES ($nome, $email, $telefone)
Logo, se o cara preencher o campo NOME por exemplo com um comando SQL, esse comando eu acho que não será executado! :).
Faça uns testes pra você ver.. se conseguir "atacar" o seu banco de dados, aí você posta uma mensagem aqui pra galera ver.. mas acho difícil mesmo! ;).
Espero ter ajudado,
Newton Wagner
Qdo vc vai adicionar dados no mySQL por exemplo, vc usaria por exemplo:
INSERT INTO tabela ('nome', 'email', 'telefone') VALUES ($nome, $email, $telefone)
Logo, se o cara preencher o campo NOME por exemplo com um comando SQL, esse comando eu acho que não será executado! :).
Faça uns testes pra você ver.. se conseguir "atacar" o seu banco de dados, aí você posta uma mensagem aqui pra galera ver.. mas acho difícil mesmo! ;).
Espero ter ajudado,
Newton Wagner
05/11/2002 1:08pm
(~22 anos atrás)
(~22 anos atrás)
Provavelmete o nome do 'engraçadinho' será gravado como 'drop table xxx'. Uma vez que na instrução SQL o valor fica entre aspas.
em todo caso você pode verificar algumas 'palavras perigosas':
if (strpos("$texto_do_engracadinho","drop")>0):
echo "Você não pode se chamar drop";
endif;
como o colega já falou, não é muito fácil ser atacado assim, uma ocorrência mais frequente está em verificações de senha, principalmente numéricas, pois não ficam entre aspas na instrucao SQL, mas não é dificil proteger-se.
exemplo:
o cara preenche o campo senha da seguinte maneira:
"1234 OR 1=1"
ficaria assim a intrucao:
$sql = "SELECT * FROM TABELA WHERE LOGIN='Joaozinho' AND SENHA=1234 OR 1=1"
a senha pode não ser 1234, mas 1 certamente será igual a 1. E o sujeito poderá logar.
em todo caso você pode verificar algumas 'palavras perigosas':
if (strpos("$texto_do_engracadinho","drop")>0):
echo "Você não pode se chamar drop";
endif;
como o colega já falou, não é muito fácil ser atacado assim, uma ocorrência mais frequente está em verificações de senha, principalmente numéricas, pois não ficam entre aspas na instrucao SQL, mas não é dificil proteger-se.
exemplo:
o cara preenche o campo senha da seguinte maneira:
"1234 OR 1=1"
ficaria assim a intrucao:
$sql = "SELECT * FROM TABELA WHERE LOGIN='Joaozinho' AND SENHA=1234 OR 1=1"
a senha pode não ser 1234, mas 1 certamente será igual a 1. E o sujeito poderá logar.
05/11/2002 9:09pm
(~22 anos atrás)
(~22 anos atrás)
Esse tipo de "ataque" é chamado de SQL Injection. Se você procurar em search engines pelo nome citado, provavelmente encontrará mais informações a respeito desse assunto, bem como possíveis soluções para esse tipo de problema.
Valeu!
Caio Filipini
Valeu!
Caio Filipini
05/11/2002 9:48pm
(~22 anos atrás)
(~22 anos atrás)
www.php.net/manual/pt_BR/security.database.php
[]s
[]s
08/11/2002 2:45pm
(~22 anos atrás)
(~22 anos atrás)
NObre colega phpeutico,
As variaveis de servidor identificam de onde esta vindo o formulario que foi enviado. Você pode alem de receber as variaveis no vetor do hhtp_post receber a string de onde estão vindo as informacoes.
Assim você evita o envio do form de qualquer outro lugar. Só recebe informações daquela página e daquele servidor.
Qualquer duvida me manda um email
As variaveis de servidor identificam de onde esta vindo o formulario que foi enviado. Você pode alem de receber as variaveis no vetor do hhtp_post receber a string de onde estão vindo as informacoes.
Assim você evita o envio do form de qualquer outro lugar. Só recebe informações daquela página e daquele servidor.
Qualquer duvida me manda um email
11/11/2002 5:28am
(~22 anos atrás)
(~22 anos atrás)
Preparei e postei um artigo explicando como ocorre e como evitar o SQLInjection. Estou aguardando a "boa vontade" dos moderadores do site para que o artigo seja posto em apresentação (demora pacas!!!!!).
19/11/2002 10:01am
(~22 anos atrás)
(~22 anos atrás)
Cuidado com a lenda SQL INJECTION....... nem sempre o q encontramos na web falando sobre ela é verdadeira. Dah uma olhada no link que o André passou.
28/11/2002 9:23pm
(~22 anos atrás)
(~22 anos atrás)
Neste caso acho que deveria ser tirados todas as aspas e aspas duplas do que for digitado. Porque assim, se o cara utilizar aspas ao preencher o formulário, digitando algo assim: "(SELECT usuario,senha FROM senhas)";
Ele vai executar a query, eu sei que é meio improvável, mas acho que deve-se retirar as aspas do cara, porque se isto for feito ele vai pegar o que o cara digitou e deixar como uma string.
Se falei besteira me avisem =)
[]s
Ele vai executar a query, eu sei que é meio improvável, mas acho que deve-se retirar as aspas do cara, porque se isto for feito ele vai pegar o que o cara digitou e deixar como uma string.
Se falei besteira me avisem =)
[]s
29/11/2002 3:46pm
(~22 anos atrás)
(~22 anos atrás)
A maneira mais sem dor de cabeça que uso para evitar SQL injection é utilizar o addslashes()
$sql = "SELECT * FROM tabela WHERE nome='".addslashes($nome)."' AND senha='".addslashes($senha)."'";
mysql_query($sql);
Simples para resolver.
$sql = "SELECT * FROM tabela WHERE nome='".addslashes($nome)."' AND senha='".addslashes($senha)."'";
mysql_query($sql);
Simples para resolver.
08/03/2003 2:44pm
(~22 anos atrás)
(~22 anos atrás)
Não podemos esquecer de outro tipo de ataque: o usuário digitar na url &nivel=admin, ou seja, há sites que colocam o nível, ou tipo de usuário na propria url (principalmente enviando esses dados como um hidden, no cadastro). Ja vi mais de 5 sites assim, cujas urls nao falo aqui por questão de ética
21/12/2003 10:38pm
(~21 anos atrás)
(~21 anos atrás)
23/10/2004 12:49pm
(~20 anos atrás)
(~20 anos atrás)
Aurelio
assim com em tuda seguranca nao exites uma receita de bolo, isto vale para qual assunto. ex.(Se soubesse que seriamos assaltados nao sairiamos com a carteiro no bolso.) rsssss
Mais existe regras que pode diminuir e muito os ataques.
1) use sempre validacao. abuse de javascritps e expressoes regulares
2) tente sempre esperar o que o usuario vai imputar de dados no seu campo. Ou seja se vc tem um campo de email no seu formulario entao so permita que no formato de email seja inseridos. a mesma coisa para numerico etc...
3) faca sempre que possivel uma segunda camada de validacao, ou seja nao se contente somente com a validacao no cliente valide tbem no seu codigo ou no seu banco.
4) se vc usa interbase,postgree pode fazer triggres de validacao (isto seria otimo).
5) sempre use '' nas suas querys isso vai evitar muitas dores de cabeca (exe. select * from noticia where id='1')
6)trate os campo de texto com funcoes como htmlentities ou htmlspecialchars
bom esses sao os passos que uso,com vc nao esta totalmente segura(ninguem esta) mais ficara um pouco mais tranquilo
assim com em tuda seguranca nao exites uma receita de bolo, isto vale para qual assunto. ex.(Se soubesse que seriamos assaltados nao sairiamos com a carteiro no bolso.) rsssss
Mais existe regras que pode diminuir e muito os ataques.
1) use sempre validacao. abuse de javascritps e expressoes regulares
2) tente sempre esperar o que o usuario vai imputar de dados no seu campo. Ou seja se vc tem um campo de email no seu formulario entao so permita que no formato de email seja inseridos. a mesma coisa para numerico etc...
3) faca sempre que possivel uma segunda camada de validacao, ou seja nao se contente somente com a validacao no cliente valide tbem no seu codigo ou no seu banco.
4) se vc usa interbase,postgree pode fazer triggres de validacao (isto seria otimo).
5) sempre use '' nas suas querys isso vai evitar muitas dores de cabeca (exe. select * from noticia where id='1')
6)trate os campo de texto com funcoes como htmlentities ou htmlspecialchars
bom esses sao os passos que uso,com vc nao esta totalmente segura(ninguem esta) mais ficara um pouco mais tranquilo
23/03/2005 7:43am
(~19 anos atrás)
(~19 anos atrás)
Não sei se é verdade ...
Mas diz um professor meu (Fera em BD)
que o mysql injection só funciona em servidor com php mau configurado...
Pq tipo vc configura alguma coisa no php q ele não aceita comandos SQL via formulario...
Mas diz um professor meu (Fera em BD)
que o mysql injection só funciona em servidor com php mau configurado...
Pq tipo vc configura alguma coisa no php q ele não aceita comandos SQL via formulario...
23/03/2005 7:44am
(~19 anos atrás)
(~19 anos atrás)
Não sei se é verdade ...
Mas diz um professor meu (Fera em BD)
que o mysql injection só funciona em servidor com php mau configurado...
Pq tipo vc configura alguma coisa no php q ele não aceita comandos SQL via formulario...
Mas diz um professor meu (Fera em BD)
que o mysql injection só funciona em servidor com php mau configurado...
Pq tipo vc configura alguma coisa no php q ele não aceita comandos SQL via formulario...