• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

REVISTAPHP

[PHP] PHP Injection

7 mensagens neste tópico

Esse artigo é apenas um pequeno resumo de inúmeras possibilidades de aplicar e evitar o PHP Injection.

Uma coisa que devemos sempre nos preocupar são nossas querystring: essas 2 abaixo são as mais usadas (paginas e includes) e claro isso é valido para outras variáveis também.

pagina.php?pag=
pagina.php?inc=

Por incrível que pareça, isso é muito comum e é com esta vulnerabilidade que muitos sites são atacados.

Por exemplo: se você fizer uma busca no google com o termo.

Esses são só sites que você irá testar, portanto facilita muito a vida, se você colocar no google allinurl: string você encontra muita coisa legal, aproximadamente 2.770.000 para allinurl: string

Com a busca você vai encontrar muita coisa do tipo:

pagina.php?pag=

Com o crescimento de muitos sites e maior facilidade no desenvolvimento, surgem claro muitos servidores mal cuidados e muitos programadores despreocupados com a segurança e com isso uma pessoa com intenção de prejudicar pode usar um exploit remoto assim:

Você tem a URL

www.qualquercoisa.xb/pasta/foto.gif

Com um exploit você pode fazer

www.qualquercoisa.xb/pasta/foto.gif?&exp=comando  (exp exploit)

Não irei entrar em questões mais técnicas que não é o objetivo, mas se com isso você pegar um servidor vulnerável, você pode escalar privilégios e poderá ter até o root da maquina, essas maquinas são usadas muito por spamers, são chamadas de maquinas Zumbi.

Algumas maneiras para melhorar a segurança seriam as listadas abaixo:

Primeiro, edite o php.ini especifique as opções:

Código:

allow_url_fopen = Off

Isso vai impedir que um include ou um open que não esteja hardcoded, ou seja, que tenham seus valores fornecidos por uma variável, façam includes remotos, como no exemplo citado no início deste post.

Código:

safe_mode = On

Isto impedirá que os scripts em PHP abram arquivos que não sejam do mesmo dono (UID) do script. Mas não esqueça de dar um chown nos scripts para um usuário sem privilégios (o nobodyserve), criando um utilizador phpscripts ou algo assim.

Código:

register_globals = Off

O "register globals" ligado diz para o PHP que qualquer variável passada como parâmetro deve ser reconhecida como uma variável válida dentro do código PHP. Isto facilita muito as coisas pois com isso não precisamos ficar associando o array $_REQUEST a variáveis internas, mas ao mesmo tempo é perigoso, pois permite a um atacante controlar variáveis internas que você não tenha corretamente incializado.

Código:

magic_quotes_gpc = On

Se você não tem conhecimento sobre como "tratar" variáveis antes de enviá-las para bancos de dados ou programas externos, uma boa opção é deixar o "magic quotes" ligado, pois ele dificulta bastante a manipulação de strings para, por exemplo, provocar um SQL Injection no seu acesso ao banco.

Código:

display_errors = Off

Ao invés de visualizar os erros de programação no browser, use o log do servidor. Esta opção impede que atacantes provoquem erros na sua aplicação para descobrirem paths da estrutura de arquivos.

Leia as demais opções do seu php.ini, especialmente se você estiver usando o PHP sob IIS/Windows. Existem coisas importantes lá, mas que nunca tive a oportunidade de usar.

Além das configurações, algumas práticas de programação podem salvar a sua pele. Por exemplo, nunca passe o nome de um ficheiro como parâmetro para um include ou fopen! É muito comum você encontrar sites com URLs do tipo http://www.sitequalquerrr.com/index.php?inc=contato

E então, quando mudamos a palavra contato para qualquer outra coisa (por exemplo "testnotfound") o PHP exibe a fatídica mensagem de erro de "Arquivo não encontrado". E atenção: não confie no seu código se você está acrescentando um path completo e a extensão do arquivo na hora de incluir, por exemplo:

Código PHP:

include("/home/asnocoder/www/includes/".$inc.".php"); 

Não confie nisso! Continua perfeitamente possível incluir qualquer arquivo do seu sistema através da manipulação correta da variável $inc.

E já que estamos falando de includes, NUNCA COLOQUE EXTENSÃO .inc NOS SEUS SCRIPTS OU BIBLIOTECAS. Estas extensões não são tratadas pelo webserver e o código fonte do programa é exibido caso eles sejam chamados diretamente no browser. Você tem três opções:

1. Renomear estes arquivos para "arquivo.inc.php", por exemplo (e alterar os includes que fazem referência a eles).

2. Mover estes arquivos para uma parte da árvore de diretórios que não seja acessível diretamente pelo browser.

3. Proteger o diretório onde estes arquivos estão. Segue exemplo de diretrizes do Apache:

Código:

<Location ~ "/[^ ](?=\.inc(\?[^ ]*)?)/">
  Options None
  Order Allow, Deny
  Deny from All
  AllowOverride None
  Satisfy All
</Location>

Quando eu tenho que fazer um include/fopen de acordo com uma opção do usuário, eu costumo criar um ninho de IFs e passar como parâmetro para a página apenas um número, ou um código qualquer, fazendo algo do tipo:

$inc = "index.php"; // Página default
if($_GET['opcao']=="1") { $inc = "pagina1.php"; }
if($_GET['opcao']=="2") { $inc = "pagina2.php"; }
include($inc);

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Excelente tópico...

tem-se de ter muito cuidado com a maneira como se programa.  senão estamos "lichados".  :D

cumps.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Artigo porreiro.

Outra alternativa a isto

(...)

Quando eu tenho que fazer um include/fopen de acordo com uma opção do usuário, eu costumo criar um ninho de IFs e passar como parâmetro para a página apenas um número, ou um código qualquer, fazendo algo do tipo:

Código PHP:

$inc = "index.php"; // Página default
if($_GET['opcao']=="1") { $inc = "pagina1.php"; }
if($_GET['opcao']=="2") { $inc = "pagina2.php"; }
include($inc);

(...)

seria usar o switch, juntamento com a opção default:

...
switch ($_GET['opcao'])
{
case '1':
{
$inc = "pagina1.php";
break;
}
case '2':
{
$inc = "pagina1.php"
break;
}
...
default: //apanha tudo o que os restantes "case" não apanham
{
...
break;
}
}
...

Eu sei que usando uma série de IF e no fim um ELSE iria dar ao mesmo, simplesmente isto é outra forma de realizar as coisas, que até pode dar jeito em alguns casos (não tendo um break; num dos case, por exemplo, de forma a realizar várias acções que podem ser independentes, e sem ter de verificar varias vezes a variavel). Enfim, outras abordagens.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Artigo porreiro.

Outra alternativa a isto

(...)

Quando eu tenho que fazer um include/fopen de acordo com uma opção do usuário, eu costumo criar um ninho de IFs e passar como parâmetro para a página apenas um número, ou um código qualquer, fazendo algo do tipo:

Código PHP:

$inc = "index.php"; // Página default
if($_GET['opcao']=="1") { $inc = "pagina1.php"; }
if($_GET['opcao']=="2") { $inc = "pagina2.php"; }
include($inc);

(...)

seria usar o switch, juntamento com a opção default:

...
switch ($_GET['opcao'])
{
case '1':
{
$inc = "pagina1.php";
break;
}
case '2':
{
$inc = "pagina1.php"
break;
}
...
default: //apanha tudo o que os restantes "case" não apanham
{
...
break;
}
}
...

Eu sei que usando uma série de IF e no fim um ELSE iria dar ao mesmo, simplesmente isto é outra forma de realizar as coisas, que até pode dar jeito em alguns casos (não tendo um break; num dos case, por exemplo, de forma a realizar várias acções que podem ser independentes, e sem ter de verificar varias vezes a variavel). Enfim, outras abordagens.

Existe aí um tópico onde foram enumeradas as várias alternativas :confused:
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Olá,

É sempre bom alertar para os perigos existentes ao utilizar scripts na net, quem é programador acaba por ter uma responsabilidade acrescida pela segurança. Claro que se o servidor onde fica alojado o script estiver mal configurado, acaba por haver vulnerabilidades, mas aí a responsabilidade poderá ser imputada ao gestor do servidor.

Os programadores devem criar regras de programação ao nível de segurança, e até, desenvolver rotinas genéricas de teste de variáveis e dados (desde a leitura num formulário até ao guardar numa base de dados), de modo a garantir a fiabilidade do sistema.

Por isso, uma vez mais, este tipo de Tópicos são importantes para informar e criar hábitos de segurança.

Cumprimentos,

LuBoc

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Acho que seria valido também ter esse artigo na revista !

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora