segunda-feira, março 15, 2010

[Dicas-L] Php Security Nem tudo que é publicado deve ser seguido

[Dicas-L] - Php Security Nem tudo que é publicado deve ser seguido

Caso não consiga visualizar esta mensagem, clique aqui.
URL deste artigo: http://www.Dicas-L.com.br/dicas-l/20100315.php

Logotipo Dicas-L, por Ricardo Burile

Acompanhe a Dicas-L no twitter

TREINAMENTOS DEXTRA

Controle de Versão de Software com Subversion - integral - Campinas - SP (Início: 18/03/2010)
Programação PHP com Banco de Dados - terças e quintas-feiras /noturno - Campinas - SP (Início: 18/03/2010)
Oracle Administração do Banco de Dados - segundas e quartas-feiras /noturno - Campinas - SP (Início: 22/03/2010)
Oracle Essencial - terças e quintas/ noturno - Campinas -SP (Início:23/032010)
Fundamentos da Linguagem de Programação Java (SL-110-SE6) - noturno - Campinas - SP (Início: 30/03/2010)
Gerência de Projetos - integral - Campinas - SP (Início:30/03/2010)
Mais informações Fones: (19) 3256-6722 (11) 2824-6722
Acompanhe a Programação de Cursos da Dextra no Twitter
Saiba mais

Php Security Nem tudo que é publicado deve ser seguido

Colaboração: Wagner Elias

Data de Publicação: 15 de março de 2010

Eu estava lendo o livro: Pro PHP Security (Chris Snyder and Michael Southwell) - Apress. É no passado mesmo, eu não li o resto, pois analisando os códigos no começo do livro encontrei algumas falhas, incluindo problemas de design e arquitetura.

1. Uso de variáveis Super Globals do Php sem sanitização - página 77

   <form action="<? $_SERVER['SCRIPT_NAME']" method="post">   <p>   username: <input type="text" name="userName" size="32" /><br />   username: <input type="password" name="userPassword" size="16" /><br />   <input type="submit" name="submit" value="login" />   <p>   </form> 

Estas variáveis como qualquer input podem ser manipuladas, o que torna este form vulnerável a XSS (Cross Site Scripting).

2. Implementação inadequada de salt - página 78

O livro começou bem neste ponto, sugerindo a utilização de salt como recurso para fortalecer os hashs de senha. Mas, como geralmente acontece, a idéia é boa mas a implementação é ruim.

   $salt = time();   $hashedPassword = sha1($userPassword . $salt); 

O código apresentado sugere gerar um hash no momento da criação baseado em time(). Como comparar este resultado na hora de cada login se o time() tem um valor que não é fixo? Eles sugerem armazenar um hash em um campo na mesma tabela de usuários, junto com o hash da senha.

   $query = 'INSERT INTO LOGIN VALUES (' . dbSafe($userName) . ', ' . dbSafe($hashedPassword) . ',' .dbSafe($salt) . ')'; 

Geralmente o comprometimento dos hashs de senhas acontece por falhas de SQL Injection, portanto se o usuário mal intencionado pega o hash e salt numa paulada só e consegue reverter a senha (óbvio que aqui estamos falando de senhas com baixa complexidade e que podem ser revertidas por base de hashs pré-compilados).

Este é o típico caso onde existe a exceção, se em código compilado e local não é recomendado a senha hard-coded, neste caso em linguagem interpretada como php, asp é mais seguro que quardar no banco, pois para comprometer o salt ele precisa ter acesso aos diretórios do servidor de aplicação.

As páginas seguintes são uma enrolação danada e nada de código, nem vulnerável. Ai fiquei curioso para ver quais eram as sugestões para controles de sessão,uma falha comum em aplicações.

3. Controle inadequado contra CSRF/XSRF (Cross Site Request Forgery) - Página 402

   <?php      $referrer = $_SERVER['HTTP_REFERER'];   if (!empty($referrer)) {   $uri = parse_url($referrer);   if ($uri['host'] != $_SERVER['HTTP_HOST']) {   exit("Form submissions from $referrer not allowed.");   }   }      else {   exit('Referrer not found. Please <a href="' . $_SERVER['SCRIP_NAME'] . '">try again</a>.');   }      ?> 

O referer é um recurso do HTTP que informa de onde a requisição está vindo, mas como é coletado usando uma variável Super Global, pode ser manipulado como analisamos no início do post na falha número 1. Controles efetivos para CSRF/XSRF são token de sessão com boa entropia e solicitar uma nova autenticação em operações críticas.

Para forjar um referer e bypassar este controle podem ser usados scripts que geram um referer, exemplo:

   <META HTTP-EQUIV="refresh" CONTENT="0;url=[url a ser atacada];"> 

Não preciso nem falar que não li o livro todo. Não recomendo, o livro não acrescenta praticamente nada em segurança e ainda comete erros grosseiros.

Blog do Autor - http://wagnerelias.com

+ comente esta mensagem

Aprenda inglês em casa
Curso estruturado com o que existe de melhor e mais rápido em estratégias e técnicas de aprendizado para adultos.
Conheça as aulas experimentais.

Dicas-L: Uma dica por dia desde 3 de março de 1997
As mensagens da lista Dicas-L são veiculadas diariamente
para 29598 assinantes.
Newsfeed RSS: http://www.dicas-l.com.br/index.xml
Caso não queira mais receber estas mensagens clique aqui.

Apoio
A Dicas-L tem o apoio da Locaweb

Nenhum comentário: