Programe PHP com segurança!

[slul]

Fonte: VivaoLinux
URL:http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=4392#
Conteúdo

Cross Site Secripting

Este documento tem como ênfase a programação com o mínimo de segurança aceitável para um sistema. Quando falamos de segurança, temos que ter noção que um projeto já deve nascer com esta preocupação. Que os programadores deste projeto também tenham esta preocupação na construção do código. Ou seja, segurança não é apenas um "coisa" de rede ou de administrador de sistema, mas também uma "coisa" de programador.

Vamos ver aqui alguns exemplos simples de códigos inseguros que podem comprometer todo um sistema.

Cross site script

Regra número um, nunca passe dados importantes via GET.

Exemplo: Uma página que usa templates onde o link para o template é passado via GET:

http://exemplo.com.br/exemplo.php?link=faleconosco.html

Isto poderia gerar um grande transtorno, pois a pessoa poderia passar qualquer endereço acima, o que poderia fazer por exemplo, que esta página funcionasse como um site pornô.


Tratamento de dados

Regra número dois, sempre que passar um dado via GET, tratar esse dado usando REGEX ou qualquer tipo de máscara para ter certeza do tipo de dado recebido.

Exemplo:

http://exemplo.com.br/exemplo.php?cod=123

$cod = int($_GET['cod']);
//isto já transformaria qualquer dado para inteiro

SQL injection

Esta regra é comumente usada por programadores desatentos. Nunca passe dados de um formulário direto para um query. Exemplo:

Código HTML:




Código PHP:

$sql = "SELECT * FROM users WHERE user=$login AND pass=$senha";
?>

Ou seja, as variáveis $login e $senha chegam direto no banco de dados sem nenhum tratamento ou o que pode acontecer.

Se o usuário digitar no login ou na senha OR "1=1", ou seja:

$user = a nada OR 1=1 -->passou
$senha = a nada OR 1=1 -->passou

e pode-se fazer muito mais....

Uma simples validação de senha e login evitaria isso, sendo este tipo de invasão muito comum e de responsabilidade do programador, não do servidor de hospedagem.


Navegação

   1. PHP: Programando com segurança
   2. Tratamento de dados e SQL injection
   3. Tipo de dados e restrição de HTML htmlspecialchars
   4. Gravar arquivos via upload


Leitura recomendada

    Dicas básicas de segurança no PHP
    Criptografando mensagens com PHP
    Usando cache na classe Fast Template
    Paginação de resultados em PHP/MySQL
    Criando backup do MySQL com o mysqldump


Comentários

Comentário enviado por profeta_livre em 03/03/2006:

só uma dúvida, se eu enviar um dado não seria melhor eu receber como a varialvel dele?

em vez de receber assim $_POST['variavel']
não seri amais prudente receber assim $variavel
?

Comentário enviado por makoto_mizuno em 03/03/2006:

profeta_livre, assim como ele falou no artigo, a opção "global vars" do PHP pode estar desabilitada e mesmo que estivesse habilitada o preferível é assim pois se mudar algum dia a configuração você não terá problemas e também tem a questão de você querer que o usuário use POST e não tente enviar por GET para driblar qquer verificação ou limitação que vc impôs, há várias coisas para citar.

Comentário enviado por chronos em 03/03/2006:

certeza, evitar register globals é a melhor coisa a se fazer, é muito inseguro.

Principalmente para sites que deixam as variaveis via get, sendo mostradas.

Meu caro leogenilhu, um bom artigo para começar, seria interessante postar links de artigos sobre segurança PHP, é muito importante para a galera que ta começando e para quem já sabe.


Comentário enviado por pezt em 03/03/2006:

ficou bom o artigo, mas não completo.
você colocou exemplos de códigos errados e tal.. mas e os códigos certos? tudo bem, é possível procurar e tal.. mas como eu disse.. não está completo.
mas não se engane.. seu artigo não está ruim.. pelo contrário.. está muito bom..

parabens



Comentário enviado por paes em 03/03/2006:

O certo ele ja falou no próprio texto, o que se deve fazer.

E não há apenas códigos errados, há os certos também, como a verificação do arquivo, da verificação da origem e do tratamento de dados. Esses são códigos corretos!

Até

Comentário enviado por bpiero em 03/03/2006:

O artigo está legal, mas não concordo em parte!

Sob o ponto de vista da segurança, não há problema algum em enviar informações pela URL. Pode-se enviar dados com POST tanto quanto por GET, não há nada que impeça o cliente de enviar o que bem entender com POST! Alias, enviar o script a ser carregado pela URL é um vantajoso, pois facilita a organização do "Favoritos". O que impede o seu website de virar um "pornstar" é o tratamento das informações recebidas dos clientes. Um simples "basename" resolve o problema, reduzindo a possibilidade de inclusão aos scripts dos diretórios de inclusão.


Tipo de dados

Quarta regra: Sempre verificar e indicar a origem da variável.

Exemplo:

$cod = $_GET['cod'] //tipo get
$cod = $_POST['cod'] //tipo post
$cod = $_SESSION['cod'] //tipo session
$cod = $_COOKIE['cod'] //tipo cookie

Já que por padrão as versões superiores a 4.2 trazem a variável global desabilitada.

Restrição de HTML htmlspecialchars

Exemplo: um formulário padrão com campos abertos como de observação onde o usuário poderia colocar no lugar de simples texto um código HTML comum, um link de foto ou até um javascript malicioso.

Para impedir isso existe um tratamento importante com a função htmlspecialchars() (ver documentação do PHP), que transforma códigos HTML em simples códigos texto.

OBS: Teremos uma classe de validação de formulários com um método com esta função seu uso será descrito na documentação da classe.



Gravar arquivos via upload

Sempre que for gravar um arquivo via upload, tenha certeza do tipo de arquivo que está gravando. Por exemplo, um arquivo de imagem pode ser simplesmente tratado usando uma validação de tipos.

Exemplo:

function type_up()
   {//Verifica se o mime-type do arquivo de imagem
     if(!eregi("^image/(pjpeg|jpeg|png|gif|bmp)$", $this->arquivo["type"])){
       return 0;
     }else{
       return 1;
     }
   }

OBS: Também teremos uma classe sobre upload que teria um método de tratamento de tipos com sua documentação de uso. Com isso não seria gravado outro tipo de arquivo que não uma imagem.

Poderíamos citar N outros casos de invasão ou insegura de um sistema. Por isso acredito que esta documentação estará sempre aberta. Porém o mais importante é ter a consciência de projetarmos desde o início o sistema pensado sempre na responsabilidade de termos SEGURANÇA.

[Anonymous]

eu até lembro quando te passei esse link, chega você gozou de felicidade, idhasihdishaduisa

[slul]

huahuauhauhahuuhahua


é né eh mto massa agora aprender a nao cometer erros que nós exploramos por tanto tempo  ;D

[Anonymous]

Só me lembrei de ti Bit, taqui um material (não sei se é muito bom, mas eu achei que dava pra ter noção de alguma coisa) sobre PHP
http://rapidshare.de/files/15235611/PHP.zip.html

[bloodrain]

eh bom usar a funçao stripslash para tirar as /  s
ou fazer um sript como esse incluido  tds as pags que usem sql:

Código Selecionar Expandir

<?php

// Anti-SQL Injection 
function checar() 
  { 
    $ruim = array(";","'","*","/"," \ ","DROP", "SELECT", "UPDATE", "DELETE", "drop", "select", "update", "delete", "WHERE", "where", "-1", "-2", "-3","-4", "-5", "-6", "-7", "-8", "-9",); 
   
    foreach($_POST as $valor) 
    { 
$valor = clean_variable($valor);

if(in_array($valor, $ruim)) 
      { 
        die("SQL Injection Detectada"); 
      } 
      else 
      { 
        $checar = preg_split("//", $valor, -1, PREG_SPLIT_OFFSET_CAPTURE); 
        foreach($checar as $char) 
        { 
          if(in_array($char, $ruim)) 
          { 
            die("SQL Injection Detectada"); 
          } 
        } 
      } 
    } 
  } 
function clean_variable($var) 
{ 
$varnova = preg_replace('/[^a-zA-Z0-9\_\-&#93;/', '', $var); 
return $varnova; 
}

?>