Neste artigo pretendo mostrar uma maneira fácil, simples e segura de fazer um sistema de autenticação em PHP com MySQL. Todas as sessões são registradas em um banco de dados com o IP, data e hora de acesso, deixando um enorme histórico excelente para futuras auditorias. Procurarei detalhar o máximo possível para facilitar a compreensão do artigo.
A página de login tem a função de um porteiro, que confere os dados do usuário e se forem positivos, redireciona-o para uma página, aqui denominada index.php. Caso os dados não confiram com o banco de dados, os usuários ficam barrados na porta.
Esta é uma ótima medida de segurança se não fosse por um problema: O que impede do cliente digitar a URL de uma página diretamente no navegador, sem passar pelo porteiro? O que aconteceria se ele fizesse isso?
Obviamente teria acesso a qualquer outra página e o tal "porteiro" não barraria nada porque o cliente estaria "pulando o muro" e uma vez dentro do prédio o acesso não é mais questionado.
Na verdade, o trabalho que devemos ter é de cercar o sistema de muros altos e intransponíveis, de forma que só seja possível entrar passando pelo porteiro. Desta forma, sim, só teria acesso aqueles que receberam autorização.
Para fazer isso colocaremos na primeira linha de cada arquivo uma verificação de autenticação, ou seja, se o cliente foi autenticado com sucesso na tela de login, poderá ter acesso ao arquivo.
[1] Comentário enviado por marcrock em 09/12/2010 - 01:52h
Ótimo artigo !!!
Quanto aos arquivos com outras estensões que não php, não existe uma opção que faça o php processar todo e qualquer tipo de arquivo ? Seria meio que um disfarce para o arquivo onde o php intercepta o carregamento e faz todas as verificações como se quele fosse um arquivo php real.
[3] Comentário enviado por malacker em 09/12/2010 - 13:20h
Caro marcrock,
Existe uma maneira de impedir que certos arquivos sejam visualizados pelo apache. No arquivo de configuração do apache, você pode inserir a regra abaixo, mas como trata-se de um remédio para uma doença que pode ser evitada, acho melhor prevenir (usando só arquivos .php) do que ter que tomar o remédio.
Mas se seu caso exige que seja feita esta medida, espero que este código possa ajudar:
# Impedindo a visualização de arquivos .inc
<Files *.inc>
Order deny,allow
deny from all
</Files>
Se deseja, pode colocar vários arquivos simultaneamente na mesma regra.
# Impedindo a visualização de vários arquivos simultaneamente.
<FilesMatch "\.(gif|jpe?g|bmp|png)$">
Order deny,allow
deny from all
</FilesMatch>
[4] Comentário enviado por reyfernandes em 09/12/2010 - 18:29h
Vou fazer um comentário sem ler completamente seu artigo, li apenas o código do login.php.
Parece que você está com o register_globals no php.ini ligado, fazendo com que qualquer variável enviada por post ou get se torne uma variável no script, ficando fácil burlar o sistema.
[5] Comentário enviado por mago_dos_chats em 09/12/2010 - 20:30h
Bom la vai meu comentario, na página de login você fez a verificação se as variaveis que o cara esta enviando de user e passwd estão em branco, mais se o cara fizer um sql injection?
Pelo jeito que esta seu sistema simplesmente vai bugar e mostrar a estrutura do banco toda.
Sugiro que você valide melhor seu formulário porque como ja dizia aquele ditado de programação .." se entrar lixo, sai lixo.".
Blz.. abraço cara
[6] Comentário enviado por malacker em 10/12/2010 - 12:03h
Não acredito que seja tão fácil burlar este login atravé de técnicas de sql injection porque o php criptografa (MD5) a variável recebida como senha e só depois a insere no banco de dados. Desta forma, qualquer coisa digitada no campo senha não será inserido literalmente no banco de dados, assim como a maioria das técnicas de sql injection.
Depois ele verifica se encontrou apenas só um cliente e só se isso for verdadeiro é que ele "loga" o cara.
O código ainda pode ser melhorado, sim (coisa que eu não fiz). Podemos colocar um "else" após o "if" que verifica se foi encontrado um só registro. Desta forma, dentro desse else, poderíamos zerar a variável $codcliente. Se o cara tentar um ataque por GET ou POST definindo um número para a variável $codcliente, o "if" trataria de zerar esta variável. É uma boa medida de segurança que deixei passar despercebida. Agradeço a quem contribuir.
[7] Comentário enviado por mago_dos_chats em 10/12/2010 - 18:58h
Sim malacker, com o MD5 o o usuario não vai ver qual a senha salva no banco, mais não acha que seria necessário proteger como seu banco esta estruturado? Legal o script para inicio, vai melhorando ele.
[9] Comentário enviado por reideer em 12/12/2010 - 10:41h
Dicas:
nunca faça o que você fez.
#reyfernandes está corretissímo.
além do que, você trata a senha encriptando ela, porém o email ta passando livre livre para injections.
coisa simples a se fazer, sempre que adicionar uma variável a sentença sql, passe o conteúdo pela função addslashes antes. Não resolve todos os problemas, mas não deixa tão na cara o rombo na segurança. Do jeito que está tá na cara do gol.
[10] Comentário enviado por chinlap em 11/03/2011 - 14:39h
Eu li e re-li esse tutorial, fiz o passo-a-passo mas está dando erros nos arquivos. No arquivo sessoes da erro na linha numero 42, e no arquivo login aparece um erro na linha 24. eu não entendo quase nada de php, estou começando nessa area, como concerto esses arquivos? oq devo fazer? me ajudem por favor amigos.
até mais
OBS: esse script funciona também em php5?
Obrigado.