Duvidas com SQL Injection e criptografia de senha

[DiF]

Em um dos topicos em que respondi.. o Mog.Lucas comentou que meu codigo tinha vulnerabilidade ao SQL Injection. procurei rever o codigo e estudar sobre isto.. bom.. em um dos artigos sobre sql injection... eu resolvi fazer os testes aqui em meu projeto...

de fato se eu escrever no campo de senha: ' or 1='1 eu estaria fazendo um sql injection certo? no meu projeto isto nao funcionou. de todas as formas que tentei...ele sempre apresentava usuario inválido.

isso se deve ao fato de eu ter encriptografado a senha no banco com a funçao Des_encrypt?

no meu validaUser.php por exemplo nao coloquei nenhuma funçao de escape.. por exemplo:

session_start();

$login = $_POST["login"];
$senha = $_POST["senha"];

$sql = "SELECT * FROM admin WHERE login='$login' AND des_decrypt(senha) = '$senha' ";

.
.
.
?>

desta forma. nenhuma de minhas tentativas de SQL injection funcionaram.. o que me intriga... pois nao usei nada mirabolante.. apenas encriptografei a senha...

também estudei uma solução caso nao tenha encriptografado fazendo desta maneira:

session_start();

$login = $_POST["login"];
$senha = $_POST["senha"];

$login_escape = addslashes($login);
$senha_escape = addslashes($senha);

$sql = "SELECT * FROM admin WHERE login='{$login_escape}' AND senha = '{$senha_escape}' ";

.
.
.
?>

bom é isso.. minha pergunta mesmo em miudos.. é saber se apenas encriptografando a senha seja em Des_encrypt, aes_encrypt ou MD5... ja é o suficiente para nao validar o sql injection?

[netofire]

Trate a variável que vem com mysql_real_escape_string().

O SQL injection não diz respeito somente a logar, mas a tomar conta de um banco inteiro, dando ao atacante privilégios de administrador.

[DiF]

sim, mas como ele poderia tomar conta do banco, se ele nao conseguir acessa-lo?

é isso que nao estou entendendo..

[Roberto.Korea]

Dif,

Tente fazer o seguinte...

Na label de login, escreva o seguinte;

';select * from admin where 1=1;--'

veja se entra;

Uma das coisas que também ajuda é, no post login e senha você utilizar função html_entites();

Pesquisa sobre essa função;

Abraços

[netofire]

sim, mas como ele poderia tomar conta do banco, se ele nao conseguir acessa-lo?

é isso que nao estou entendendo..

você não conseguiu.

Uma variável de usuário sem tratamento, na mão de quem manja, é fatal.

[Mog.Lucas]

O próprio PHP tem uma configuração em seu arquivo php.ini que "trata" (utiliza addslashes) automaticamente todos os dados de requisições, ou seja, dados enviados pelo usuario. Essa função embora muito eficaz para proteção (não que seja a unica que se deve ser tomada) acaba, na verdade, trazendo problemas para o resto do sistema e é até mesmo uma função deprecated.

Eu lhe alertei para que veja melhor o lado da segurança. Talvez seja porque eu faço o treinamento de segurança aqui do fórum e seja meio obcecado com isso hehehe.. Mas acredito que se você se preparar no começo será melhor lá na frente. Alterar a segurança de um sistema (como eu faço as vezes no meu trabalho) é mil vezes mais difícil do que começar um sistema já com segurança.

Quanto ao SQL Injection, o seu primeiro código é vulneravel (desde que não tenha aquela função do PHP citada ativada), já o segundo (com addslashes) não.

$sql = "SELECT * FROM admin WHERE login='$login' AND des_decrypt(senha) = '$senha' ";

Experiente digitar no campo senha:

' or ''='
ou
' or '1'='1

A função do SQL não irá previnir ataques a SQL Injection.

PS: Tenhamos cuidado com os dados postados nesse tópico. Se qualquer informação aqui postada possa causar danos a terceiros (mesmo que indiretamente) ela será removida.

Abraços!

[DiF]

Obrigado a todos,

mog.lucas, netofire e roberto pelos esclarecimentos e avisos!

nao me importo que este topico seja deletado se causar algum dano.. mas pra mim ja serviu de liçao e aqueles dois ultimos codigos que o mog.lucas postou realmente funcionou.. então optei por usar a funçao addslashes() e realmente nao deixou efetuar o login.

eu nao tinha muito conhecimento nisso porque terei agora no sexto semestre a cadeira de segurança que provavelmente iria ver esta questao da segurança.

Pela minha interpretaçao das respostas, só encriptografando as senhas nao resolve, é necessário uma funçao de escape seja com addslashes(), mysql_real_escape_string() ou html_entites().. sendos que estas duas ultimas ainda nao tive oportunidade de pesquisar.. vou fazer isto.

so tenho mais uma pergunta, qual a diferença e eficiencia dentre estas 3? eu utilizei apenas o addslashes() por enquanto e ajudou a nao fazer login com sql injection da forma q o mog.lucas citou acima.

[netofire]

addslashes() simplesmente escapa os caracteres

mysql_real_escape_string() também, mas leva em conta o charset utilizado

Dependendo do ataque e mais alguns fatores, ele é imune a addslashes(), no caso de você passar um caractere, por exemplo, no formato 0xbf27

Mas.... basicamente fazem a mesma coisa.

A dica que eu dou é: tá estudando ainda? Corre da biblioteca padrão do MySQL e aprende MySQLi - o próprio manual diz que é a extensão MySQL melhorada. Além de ser melhorada, ela pode ser utilizada tanto procedural quanto OO pra quem ainda não tá familiarizado (ou não gosta) e é um pulo de aprender.

[DiF]

É eu realmente nao tinha conhecimento desse MySQLI, achava que era uma variaçao só... por isso nunca o utilizei nem sequer pesquisei sobre... bom minha ideia no futuro é implementar em OO. por enquanto no meu projeto estou usando a procedural mesmo.

li num artigo que nao teria problemas se usar o addslashes() com utf-8.. mas pode estar equivocado... também li que mysql_real_escape_string() também nao era 100% eficiente que teria que fazer uma funçao para expressao regular no uso do LIKE por exemplo..

de qualquer forma, vou pesquisar sobre esta extensao do mysql vou tentar adaptar ao meu projeto.

obrigado estas duvidas foram esclarecidas.. a principio nao tenho mais o que perguntar.. podem encerrar o topico se quiser.

abraços

[netofire]

É tranquilo de aprender, justamente pelo fato dele ser "preparado" pra procedural e OO, além de muitos comandos serem bem parecidos com o similar da biblioteca padrão. É só questão de ler, fazer uns testes aí e correr pro abraço.

[Roberto.Korea]

Você perguntou do htmlentites();

Bom.. Vou mostrar um trecho que eu tirei do php.net:

 [COLOR=#000000] [COLOR=Black][COLOR=#0000bb]<?php
$str [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#dd0000]"A 'quote' is <b>bold</b>"[/COLOR][COLOR=#007700];

[/COLOR][COLOR=#ff8000]// Outputs: A 'quote' is <b>bold</b>
[/COLOR][COLOR=#007700]echo [/COLOR][COLOR=#0000bb]htmlentities[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000bb]$str[/COLOR][COLOR=#007700]);

[/COLOR][COLOR=#ff8000]// Outputs: A 'quote' is <b>bold</b>
[/COLOR][COLOR=#007700]echo [/COLOR][COLOR=#0000bb]htmlentities[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000bb]$str[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000bb]ENT_QUOTES[/COLOR][COLOR=#007700]);
[/COLOR][/COLOR][COLOR=#0000bb][COLOR=Black]?>
[/COLOR][/COLOR][/COLOR]

Como você pode perceber, < > e qualquer outro caracter especial, é totalmente tratado.

Isso é bom, porque esses caracteres que passaram por tratamento, não influenciam de nenhum modo na hora de você fazer a sql.

Todas as vezes que eu recebo algum parâmetro que pode ser tratado pelo usuário, e que pode ser maliciosos, eu trato com o htmlentites.

Uma outra coisa também, que pode ser feita, é você dar um str_replace em apóstrofos e aspas, impedindo assim, eles de serem colocados nos texts.

No caso, da senha, que você poderia colocar caracteres especiais, só encriptar o código antes de gravar no banco, e em todas as vezes que você for fazer a comparação faça com os dados encriptador.

Se quiser saber mais sobre o htmlentites:

http://php.net/manual/en/function.htmlentities.php

[Mog.Lucas]

Você não costuma utilizar phpmailer ao invés do php puro? Embora eu não concorde 100%, entendo e aceito seus motivos (nem sei quais são mas posso imaginar )

Pois te digo o mesmo para conexão com banco de dados. Se você quer começar a desenvolver profissionalmente esqueça as funções mysql_*. Utilize PDO. Além de motivos de segurança, a mesma facilita quando/se você for migrar o banco para outro sistema.

PS: claro, isso é relativo ao sistema. É igual criar um sistema pequeno utilizando POO: burrice de fãzinho de POO.

PS2: Criptografia de senhas é uma obrigação de todo programador.

Abraços!

[DiF]

sim. costumo usar o phpmailer para envio de emails, por ser mais fácil e tal.. ja tentei usar propria funçao mail() do php mas nunca dava certo.. dava erro de porta.. com o phpmailer funciona tranquilamente.

PDO, certamente concordo embora ja tenho tentado uma conexao com o banco de dados e efetuar uma simples query.. nao obtive sucesso.. ainda sou inexperiente em POO, mas estou estudando.

sobre a criptografia, sempre uso também. atualmente tenho usado o DES_ENCRYPT e DES_DECRYPT .. mas to pensando seriamente em passar a utlizar o MD5 apenas.. e para recuperaçao de senha, fazer o usuario re-definir a mesma.. uma vez que encriptada em MD5 nao há mais volta de recuperar.. só re-definindo

[pedroserquiz]

pow cara, o anti sql injection nada mais é que o bloqueio da utilização de comandos, / *... etc etc....

quem consegui utilizar esses comandos, pode fazer deste uma consulta no seu banco atraves do input, ate deletar tabelas do seu banco..... tem gente que usa o injection, nao apenas para invadir um sistema, usa apenas por maldade destruindo o banco e gerando perda de dados.... ou seja..... iria destruir seu sistema....

encriptar senha funciona sim para que nao entrem no seu sistema... mas se ele faz uma consulta no seu banco pega os dados encriptografados e em seguida converte?

entende? no meu ponto de vista a utilizacao do anti sql injection é apenas para que nao possam utilizar certos comandos para acessar seu banco

se eu estiver enganado ou faltar algo me ajudem =D que tambem gosto de aprender hehehe

abraços

[DiF]

é esta parte de problema eu ja entendi, e por sinal terei aulas sobre isso no sexto semestre da faculdade. então ja estou um pouco adiantado e o pessoal aqui conseguiu me esclarecer os principais problemas causados pelo sql injection. por hora consegui por uma solução simples, porém estou ciente que o addslashes() nao é 100% seguro.. alias as outras funçoes apresentadas também nao sao 100%.. mas enfim por hora ja me resolveu!

gostaria de agradecer o pessoal que me ajudou a esclarecer estas duvidas.. portanto consisero este topico encerrado.

abraço pessoal

[Mog.Lucas]

Só uma observação, existem criptografias de mão-unica que (teoricamente) impedem a sua reversão, logo, uma vez criptografadas no banco não há como recuperar. Então mesmo que alguem roubasse seu banco ele não teria acesso a informações sigilosas.

[Mog.Lucas]

Caso o autor do tópico necessite, o mesmo será reaberto, para isso deverá entrar em contato com a moderação solicitando o desbloqueio.