+3
Principais erros de segurança em códigos PHP
- 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:
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/
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/
Parabéns pelo artigo! :-)
31/03/2011 2:13am
(~13 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.
Muito bom o seu artigo.
As vezes até eu esqueço essas boas práticas.
17/11/2008 4:36am
(~15 anos atrás)
Ricardo Gama
disse:
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
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
(~15 anos atrás)
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.
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
(~15 anos atrás)
Ricardo Gama
disse:
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?
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
(~15 anos atrás)
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.
No caso de SQL sim e é o que se chama de SQL injection.
04/11/2008 3:52am
(~15 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]
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
(~15 anos atrás)
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
muitos sistemas nao fazem validação do tipo de arquivo enviado, permitindo que arquivos .php, por exemplo, sejam enviados
30/09/2008 1:27am
(~15 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
(~15 anos atrás)