Veja a história completa neste post e a matéria que causou toda reação aqui.

O que você pode fazer?

Entre neste abaixo assinado que exige uma retratação da Rede Globo e deixe seu nome. Vamos unir a comunidade PHP e evitar esta desinformação e mancha do nosso trabalho.

Rafael Dohms

Rafael Dohms é um Evangelista PHP e membro ativo da Comunidade PHP. Ele ajudou na fundação de dois Grupos de Usuários de PHP ao longo do tempo e hoje compatilha a coordenação do PHPSP. Desenvolvedor, gamer e apaixonado por código ele também é host do primeiro podcast de PHP do Brasil: PHPSPCast. Atualmente ele trabalha na equipe SWAT do grupo MIH, uma equipe de experts que fornecem conhecimento técnico para o grupo além de trabalhar com P&D buscando novos nichos da internet e tecnologia. Seu papel como Desenvolvedor Sênior é codar, treinar e auxiliar outras empresas e se divertir enquanto faz isso.

Website - Twitter - More Posts

O que são ataques CSRF?

CSRF é um ataque que força um usuário final à executar ações indesejadas em uma aplicação web em que ele(a) está autenticado no momento. Com uma pequena ajuda da engenharia social (como enviar um link por e-mail ou chat), um atacante pode forçar os usuários de uma aplicação web para executar ações de escolha do atacante. Um CSRF  bem sucedido, pode comprometer os dados e funcionamento do usuário final caso o mesmo seja um usuário comum ao sistema. Se o usuário final for administrador, isso pode comprometer a aplicação Web inteira.

Exemplos de ataques

Como funciona o ataque? Há inúmeras maneiras em que um usuário final pode ser levado a carga de informações ou enviar informação para uma aplicação web. A fim de executar um ataque, devemos primeiro entender como gerar um pedido malicioso para a nossa vítima executar.

Vejamos o seguinte exemplo: Alice deseja transferir R$ 100,00 a João usando banco.com.br.  O pedido gerado por Alice será semelhante ao seguinte:

POST http://banco.com.br/transfer.do
HTTP/1.1.........Content-Length: 19;
acct=JOAO&amount=100

No entanto, percebe que Maria da mesma aplicação web irá executar a mesma transferência usando parâmetros de URL da seguinte forma:

GET http://banco.com.br/transfer.do?acct=JOAO&amount=100
HTTP/1.1

Maria decide agora para explorar esta vulnerabilidade de aplicações web usando Alice como sua vítima. Maria primeiro constrói a seguinte URL, que vai transferir R$ 100.000,00 da conta de Alice à sua conta:

http://banco.com.br/transfer.do?acct=MARIA&amount=100000

Agora que seu pedido mal-intencionado é gerado, Maria  tem truque para apresentar o pedido. O método mais básico é o de enviar um e-mail HTML para Alice contendo o seguinte:

<a href="http://banco.com.br/transfer.do?acct=MARIA&amount=100000">
Veja minhas fotos do Orkut!
</a>

Supondo que Alice esta autenticada com a aplicação, quando ela clica no link, a transferência de R$ 100.000 para a conta de Maria irá ocorrer.

No entanto, Maria percebe que se Alice clica no link, em seguida, Alice vai notar que a transferência ocorreu.

Por isso, Maria decide esconder o ataque em uma imagem de zero bytes:

</pre>
<img src="http://banco.com.br/transfer.do?acct=MARIA&amount=100000" alt="" width="1" height="1" border="0" />
<pre>

Se essa tag de imagem for incluída no e-mail, Alice só vê uma pequena caixa que indica que o navegador não pode processar a imagem. No entanto, o navegador continua a enviar a solicitação para banco.com.br sem qualquer indicação visual de que atransferência tenha ocorrido.

Este exemplo, pode ocorrer em qualquer aplicação que não possua tratamento no controle de formulários e/ou outros meios de entrada de dados.

Podemos ver um exemplo de como prevenir isto em outro exemplo abaixo:

O que fazer?

Ações em sites estão sempre associados com formulários – login, transferência de fundos ou postar um comentário no blog. Nossa solução para o problema de CSRF é gerar uma chave única quando o usuário visita a página com o formulário-lo. Vamos definir esta chave na $_SESSION, bem como um campo hidden no formulário. Quando o formulário for enviado, vamos verificar a chave armazenada na sessão e a chave enviada pelo formulário. Se eles são os mesmos então nós sabemos que o usuário submeteu nosso formulário. Se eles não são iguais (ou a $_SESSION está vazia), então sabemos que algo nocivo está acontecendo e nós podemos seguramente redirecionar o usuário (e não tomar nenhuma ação).

session_start ();

 // Se o formulário foi enviado ..
 if (isset ($_POST['submit']))
 {  // Verificar os marcadores
     if ($_SESSION["csrfToken '] == $_POST[' csrfToken '])
     {
         echo "form do bem";
     }   else   {
         echo "Ops, solicitação não permitida"; exit;
     }
 }   else  { // Gerar o token

     $Token = md5 (uniqid (rand (), true));

     // Definir o token como uma sessão
     $_SESSION['CsrfToken'] = $ token;

     // O nosso formulário com o campo oculto
     $ Form = '</pre>
<form action="" method="POST">  Conta: <input type="text" name="account" />
   Valor: <input type="text" name="amount" />
   <input type="hidden" name="csrfToken" value="'.$token.'" />   <input type="submit" name="submit" value="Enviar Bufunfa" /> </form>
<pre>
 ';

     echo $form;
 }

Podemos acrescentar um nível adicional de segurança, certificando-se o usuário veio a partir da página que contém o formulário.

// Antes da verificação CSRF
if (! $_SERVER['HTTP_REFERER'] == 'http://banco.com.br/formulario/transferencia/enviar.php)
{
    echo "Solicitação mal formada";  exit;
}

Obrigado pela atenção espero ter ajudado.

Kinn Coelho Julião

http://linkedin.com/in/kinncj

Website - Twitter - Facebook - More Posts

Após um longo periodo de turbulencia estamos de volta com um cast repleto de informações. Desta vez nos reunimos com Er Galvão Abott, líder do PHPBR e Diretor de Conteudo da PHP Conference Brasil para comentar um assunto chave para qualquer desenvolvedor, Segurança. Acompanhe enquanto comentamos estatisticas de segurança da internet, formas diferentes de atacar/defender sites, novas estratégias de segurança e revemos os 2 mandamentos de segurança do PHP.

Links comentados durante o podcast

• Segundo encontro PHPMG
• PHP Conference Brasil
• OWASP
• PHP Brasil Comunidades
• Curso Top 10 OWASP
• Curso PHP OO

Escute!

Assine!

Assine o PHPSPCast: http://feeds2.feedburner.com/phpspcast

No iTunes:

Quer assinar o PHPSPCast em seu iTunes? Clique aqui e saiba como assinar pelo iTunes ou fazer o download pelo iPhone/iPod!

Recados!

Elogios, críticas, sugestões, dúvidas ou #fail sobre este episódio? Idéias, temas e dúvidas para o próximo PHPSPCast? Mande email para phpspcast@phpsp.org.br ou um recado de voz para phpspcast@phpsp.org.br pelo Google Talk.

Rafael Dohms

Rafael Dohms é um Evangelista PHP e membro ativo da Comunidade PHP. Ele ajudou na fundação de dois Grupos de Usuários de PHP ao longo do tempo e hoje compatilha a coordenação do PHPSP. Desenvolvedor, gamer e apaixonado por código ele também é host do primeiro podcast de PHP do Brasil: PHPSPCast. Atualmente ele trabalha na equipe SWAT do grupo MIH, uma equipe de experts que fornecem conhecimento técnico para o grupo além de trabalhar com P&D buscando novos nichos da internet e tecnologia. Seu papel como Desenvolvedor Sênior é codar, treinar e auxiliar outras empresas e se divertir enquanto faz isso.

Website - Twitter - More Posts

    1 <?php
    2  if ($_SERVER['REMOTE_ADDR'] == '192.168.2.89')
    3  {
    4    phpinfo();
    5  } else {
    6    echo "<h1>You're like, not authorized to view this.</h1>";
    7  }
    8 ?>

A falha se encontra no fato de que não se deve confiar na variável $_SERVER. É comum as pessoas acreditarem que quem fornece esses dados é o servidor http e que eles são intocáveis. Mas a super global $_SERVER é tão manipulável quanto qualquer outra variável, portanto o que foi criado acima foi uma falsa idéia de segurança.
O post original pode ser encontrado aqui.

Augusto Pascutti

Augusto Pascutti é desenvolvedor PHP a 5 anos, trabalhou em projetos Open Source como CakePHP, Zend Framework e Habari. É evangelista PHP e de boas práticas, Zend Certified Engineer para PHP 5, fundador/coordenador do PHPSP, host do PHPSPCast e headbanger nas horas vagas.

Website - More Posts