+5
PHP: Programando com Segurança
Vamos ver aqui alguns exemplos simples de códigos inseguros que podem comprometer todo um sistema.
1) XSS (Cross Site Scripting)
Regra número um - nunca passe dados importantes via GET.
Exemplo: 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 pagina funcionaria como um site pornô.
2) Tratamento de Dados
Regra numero dois - sempre que passar um dado via GET tratar esse dado usando REGEX ou qualquer tipo de mascara, para ter certeza do tipo de dado recebido.
Exemplo: http://exemplo.com.br/exemplo.php?cod=123
3) SQL Injection
Esta regra é normalmente usada por programadores desatentos. Nunca passe dados de um formulário direto para um query.
Código HTML:
Código PHP:
Ou seja as variáveis $login e $senha chegam direto no banco de dados sem nenhum tratamento.
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.
4) Tipo de Dados)
Quarta regra: Sempre verificar e indicar a origem da variavel.
Exemplo:
Já que por padrão as versões superiores a 4.2 trazem a variável global desabilitada.
5) Restrição de HTML pela função htmlspecialchars()
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 texto puro.
6) 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 validacão de tipos.
Exemplo:
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 insegurança 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 inicio o sistema pensado sempre na responsabilidade de termos SEGURANÇA.
Leo Genilhu
www.genilhu.com
1) XSS (Cross Site Scripting)
Regra número um - nunca passe dados importantes via GET.
Exemplo: 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 pagina funcionaria como um site pornô.
2) Tratamento de Dados
Regra numero dois - sempre que passar um dado via GET tratar esse dado usando REGEX ou qualquer tipo de mascara, para ter certeza do tipo de dado recebido.
Exemplo: http://exemplo.com.br/exemplo.php?cod=123
<?php // isto já transformaria qualquer dado para inteiro $cod = int($_GET['cod']); ?>
3) SQL Injection
Esta regra é normalmente usada por programadores desatentos. Nunca passe dados de um formulário direto para um query.
Código HTML:
<input type=text name=login> <input type=password name=senha>
Código PHP:
<?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.
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.
4) Tipo de Dados)
Quarta regra: Sempre verificar e indicar a origem da variavel.
Exemplo:
<?php $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.
5) Restrição de HTML pela função htmlspecialchars()
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 texto puro.
6) 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 validacão de tipos.
Exemplo:
<?php
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;
}
}
?>
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 insegurança 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 inicio o sistema pensado sempre na responsabilidade de termos SEGURANÇA.
Leo Genilhu
www.genilhu.com
Uma dica: toda senha em banco de dados deve sempre estar criptografada, nunca em plain text. Caso alguém não autorizado consiga acesso a base de dados, não saberá qual a senha do usuário. Use qualquer algoritmos de criptografia, até mesmo md5 (função md5() resolve). Com isso, na validação, a comparação com o valor do campo senha do banco deve ser sempre feita com o valor do campo do form passado com md5, logo, a possibilidade de passar 1=1 já é eliminada, pois teríamos:
select * from usuario where usuario='$usuario' and senha='".md5($senha)."'"
Se $senha for 1=1 então transformada em um hash que não surtirá efeito...
Ah! E sempre coloque o valor que será comparado no WHERE entre aspas simples. Isto evita muitos problemas (inclusive o SQL Injection)
select * from usuario where usuario='$usuario' and senha='".md5($senha)."'"
Se $senha for 1=1 então transformada em um hash que não surtirá efeito...
Ah! E sempre coloque o valor que será comparado no WHERE entre aspas simples. Isto evita muitos problemas (inclusive o SQL Injection)
11/12/2005 12:07pm
(~19 anos atrás)
Valeu pelas dicas de um assunto tão importante da nossa área... muito bom mesmo.
18/11/2005 12:09pm
(~19 anos atrás)
Boa iniciativa, coloquem muito mais sobre segurança. Adorei, ainda mais com os comentários tudo fica melhor, Obrigado a todos.
10/11/2005 10:04pm
(~19 anos atrás)
Pra quem gostar esse site pode ser interessante para incrementar os seus scripts.
http://www.numaboa.com.br/criptologia/
http://www.numaboa.com.br/criptologia/
25/10/2005 6:49pm
(~19 anos atrás)
galera, o que foi dito aqui e muuuuuito mais tem nesse site aqui: www.phpsec.org
aí tem muuuuuita coisa de segurança.... extremamente útil... ele dá exemplos até de como o kra pode roubar um POST, ou até uma SESSION do php..
uma outra coisa legal é q, por medidas de segurança tb, recomenda-se declarar todas as variáveis do código antes de iniciar um programa, uma função ou algo do tipo
todas essas regrinhas mostram q o php num eh tao livre assim pra se programar..
aí tem muuuuuita coisa de segurança.... extremamente útil... ele dá exemplos até de como o kra pode roubar um POST, ou até uma SESSION do php..
uma outra coisa legal é q, por medidas de segurança tb, recomenda-se declarar todas as variáveis do código antes de iniciar um programa, uma função ou algo do tipo
todas essas regrinhas mostram q o php num eh tao livre assim pra se programar..
25/10/2005 7:50am
(~19 anos atrás)
O artigo é um ótimo começo para se preocupar com o assunto. Acho que faltou apenas falar um pouco mais de sanitization/sanitarização dos dados recebidos.
24/10/2005 10:49pm
(~19 anos atrás)
muito otimo essa materia ^.^ com certeza o maior responsavel por perda de dados atravez de invasao é o programador intão cuidado de mais nunca faz mal ;)
12/10/2005 1:51pm
(~19 anos atrás)
Abraços!!!