Arquivos históricos do BR-Linux.org apresenta:

Bloqueando acesso aos includes no PHP

Notícia publicada por brain em novembro 3, 2003 10:18 AM | TrackBack


José Oliveira (jbon@tci.ufal.br) disse: "Esse artigo ensina uma técnica bem simples de como impedir o acesso dos usuários aos arquivos de includes pelo browser, essa que é uma das vulnerabilidades mais encontradas em aplicações em PHP escritas por programadores inexperientes. Demonstra um exemplo bem simples do estrago que um usuário mal intencionado pode fazer em cima dessa vulnerabilidade."

 

Comentários dos leitores
(Termos de Uso)

» Flavio Moreira () em 03/11 10:27

No exemplo citado (sql injection) existe também uma outra prática errada : Executar uma instrução passa como parâmetro ... isso JAMAIS deveria ocorrer. Quem quiser se aprofundar no assunto deve procurar saber sobre "sanitização" da "query_string" ,,, um exemplo "tosco" :

$a=($QUERY_STRING);
if (get_magic_quotes_gpc()) {
$var = stripslashes($a);
}
$a = strip_tags($a);
$a = htmlspecialchars($a);
$a = str_replace("\n", " ", $a);
$a = str_replace("\r", " ", $a);
$a = trim($a);

Você terá em "$a" uma "query_string" livre de códigos maliciosos ...


» Roberto () em 03/11 11:37

Uma alternativa simples é colocar todos os arquivos que você pretende incluir em um diretório fora da árvore do servidor de páginas, lembrando de adicioná-lo no include path no arquivo php.ini.

No meu caso, as páginas ficam no diretório /usr/local/www/data, e os arquivos include do PHP em /usr/local/www/includes. Dessa maneira, é impossível acessar diretamente os arquivos include.


» José Oliveira () em 03/11 17:13

Perfeito. Mas como nem sempre é possível que o programador manipule a localização ou a estrutura de diretórios, eu propus uma solução na camada de aplicação, que é acessível em todos os casos.

Aquele exemplo não deve ser levado em consideração, só está lá pra escancarar a falha. O erro mais comum quando se acessa um include pelo browser são as variáveis não definidas, que acabam entregando informações importantes ao usuário...

Um tratamento de erro bem feito é algo imprencidível...


» José Oliveira () em 03/11 18:24

Sobre o SQL Injection, se você reparar bem a query naquele exemplo não é passada como parametro! O que tá ocorrendo é um uso da vulnerabilidade de poder acessar include pelo browser pra inserir uma query string maliciosa!


» Peter Parker () em 03/11 18:26

Esse tipo de erro não deixa de existir quando se usa o PHP com as variáveis da versão 4, ou seja, $HTTP_GET_VARS (pra get) e etc, pra diferenciar das variáveis internas?


» José Oliveira () em 03/11 19:13

Mas, infelizmente, a realidade é que em muitas empresas de hosting os administradores deixam a diretiva register_globals setada em On para facilitar a vida dos "programadores"...


» Julio Nobrega () em 03/11 19:15

@Peter Parker

Não, não deixa, se você pegar as variáveis de um formulário post:

$sql .= "WHERE username = '" . $_POST['username'] . "' ";

O cara vai lá no formulário e põe o que ele quiser.

Ajuda, porque força você a usar valores que virão de lugares que você espera, mas não sendo _o que_ você espera. Ainda precisa conferir...


Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.



O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação, layout, tabela de caracteres, etc.) o acervo de notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter de acervo, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.