+3

Principais erros de segurança em códigos PHP

criado por Marcos Regis em 12/06/2008 8:17am
- Se você não quer que o conteúdo de um arquivo seja visível, de a ele a extensão .php.

Foi uma prática muito comum por um período nomear arquivos de inclusão ou de biblioteca com as extensões .inc. Existe aqui um problema: se um usuário malicioso simplesmentes entrar com o nome do arquivo .inc em seu navegador, ele será exibido como um arquivo texto, não parseado como PHP. Ainda que o browser não entenda o tipo do arquivo, uma opção de fazer download dele poderá ser dada.

Imagine se estes arquivos contiverem as informações de acesso a seu banco de dados como o nome de usuário e a senha, ou informações ainda mais sensíveis.

Isto vale para outras extensões que não .php (e umas poucas outras), então ainda um arquivo .conf ou .cfg não serão seguros.

A solução é colocar a extensão .php ao final deles. Desde que seus arquivos de inclusão ou de configuração normalmente somente definem variáveis e/ou funções e realmente não têm nenhuma saída, se seu usuário for carregar assim, por exemplo, dentro do navegador:

http://yoursite.com/lib.inc.php

Ele normalmente não verá nada, a menos que seu script lib.inc.php tenha alguma saída. Desta forma, o arquivo poderá ser parseado como PHP ao invés de somente exibir seu código.

Há ainda algums relatos de pessoas que adicionando diretivas ao Apache para negar acesso aos arquivos .inc; contudo, eu não recomendo porque há um lapso de portabilidade. Se você der suporte a arquivos .inc e que a diretiva do Apache negue acesso a eles um dia você pode mover seus script para um outro servidor e esquecer de colocar a diretiva nele, você estará totalmente aberto.

Essas são dicas que os mais experientes programadores em PHP recomendam para a criação de scripts àqueles que estão iniciando.

Quem usa Orientação a Objetos ou algum tipo de framework também está sujeito às falhas descritas e não deve confiar totalmente no fato de separar HTML do código.

Fontes utilizadas neste artigo:
http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/

Comentários:

Mostrando 1 - 10 de 24 comentários
Parabéns pelo artigo! :-)
31/03/2011 2:13am (~7 anos atrás)

Dam disse:
Bom artigo.
20/11/2008 4:21am (~9 anos atrás)

Por incrível que pareça, já peguei muito código de programador experiente contento estes erros.

Muito bom o seu artigo.

As vezes até eu esqueço essas boas práticas.
17/11/2008 4:36am (~9 anos atrás)

Ricardo Gama disse:
a ta. Foi isso mesmo que a gente fez aqui. No config.inc.php tem uma autoload que já inclui classes comuns a do framework e instancia tbm classes comuns ao sistema.

Vlw ae... vou ver uma forma de passar isso de outro jeito... tem algum tempo que isso me incomoda de ficar na URL :)

Abcs
13/11/2008 9:09am (~9 anos atrás)

Marcos Regis disse:
Isso depende de como está o código de verificação e de include.
O que desaconselho é usar variaveis que apontem para arquivos em um include pois um hacker pode fazer seu sistema apontar para um arquivo dele e dessa forma comprometer seu sistema.
A forma que os frameworks como cake, symfony, phpmvc, etc usam tem a ver com sessao (controller) e acao (metodo).
Dessa forma não tem que dar nenhum include.
Um sistema baseado em Orientação a Objetos a meu modo de ver tem que fazer uso de autoload e ter uma lista de classes válidas a serem instanciadas (disptatcher).

Quanto a estar certo ou errado é ponto de vista mas acho que vc ganharia em segurança se não utiliza-se include por parâmetros via URL.
13/11/2008 8:38am (~9 anos atrás)

Ricardo Gama disse:
Marcos, não entendi o lance que vc falou dos frameworks...

Exemplo, aqui na empresa a gente criou um framework, que funciona mais ou menos do jeito que vc falou. Ex.:

URL:

www.sitetal.com.br/sistema/index.php?t=pedido&a=frm

o parâmetro "t" é o nome da pasta onde fica a página vindo pelo valor de a (ou seja, ele vai procurar se na pasta pedido, existe uma página chamada frm.php). Se tiver ele da o include vai na pasta de classes e instancia a classe class.PEDIDO.php...

Os métodos são chamados na própria página, conforme for preciso. A gente não passa método via URL.

Você acha que essa forma ta errada? Por que estaria? Como posso corrigir isso?
13/11/2008 8:05am (~9 anos atrás)

Marcos Regis disse:
Essa sua preocupação tem sentido quando se usa eval() da forma como mencionei no artigo, pois eval executa uma string como código php.

No caso de SQL sim e é o que se chama de SQL injection.
04/11/2008 3:52am (~9 anos atrás)

Existe por exemplo algum função que é executada mesmo sem eu chama-la??

exemplo se eu pego $_GET['nome'] e faço $nome = $_GET['nome']; e depois disso eu faço os tratamentos de segurança

ai o usuário malicioso digita funcao_maliciosa(); , ele vai guardar isso como uma string ou como uma função??
pq se acontece de $nome = funcao_maliciosa(); ai pode ser que ele consiga dados mas se gravar como string acho que nao faz diferença.

[Na verdade eu tenho quase certeza que isso nao é um problema mas é só pra tirar as dúvidas mesmo]
03/11/2008 4:49pm (~9 anos atrás)

hinom disse:
outro tipo de falha muito comum é com upload de arquivos.

muitos sistemas nao fazem validação do tipo de arquivo enviado, permitindo que arquivos .php, por exemplo, sejam enviados

30/09/2008 1:27am (~9 anos atrás)

O codigo javascript pode ser facil e util mas e haqueavel, e quando o meu pc ficou sem java, eu nao acessava os arquivos corretos, entao tive que baixar o FF. Eu recomendo a todos aqui a usarem o PHP, e logo farei outros tutoriais...
16/09/2008 5:51am (~9 anos atrás)

Novo Comentário:

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