De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

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