Cross-site request forgery (CSRF) é um exploit comum e grave, onde um usuário é levado a executar uma ação que não explicitamente a intenção de fazer. Isso pode acontecer quando, por exemplo, o usuário é conectado para um de seus sites favoritos e começa a clicar em um link aparentemente inofensivo. No fundo, a sua informação de perfil é atualizada silenciosamente com o endereço de um atacante e-mail. O atacante pode então usar o recurso do site de redefinição de senha por e-mail-se uma nova senha e ela é só sucesso roubado a conta.
Qualquer ação que um usuário tem permissão para executar enquanto estiver logado em um site, um atacante pode executar em seu / nome dela, se é atualizar um perfil, adicionar itens a um carrinho de compras, postar mensagens em um fórum, ou praticamente qualquer outra coisa.
Se você nunca ouviu falar de CSRF antes ou você não escreveu seu código com a prevenção em mente, então eu odeio a quebrá-lo para você, mas mais do que provavelmente você está vulnerável. Neste guia vou mostrar a você exatamente como CSRF ataques de trabalho eo que você pode fazer para proteger seus usuários.
Como Funciona
Para entender como um ataque de CSRF funciona, é melhor vê-lo em ação. Para ilustrar um ataque, eu gostaria de criar um exemplo simples que tem a capacidade de sair de uma sessão ativa. Vamos precisar de uma página de login ( login.php ), um script de processamento para lidar com login e logout da sessão ( process.php ) e, finalmente, um exemplo de ataque (harmless.html ).
Primeiro, aqui está o código para login.php :
<? Php
session_start ();
?>
<html>
<body>
<? Php
se (isset ( $ _SESSION [ "user" ])) {
echo "Bem vindo de volta <p>" . $ _SESSION [ "user" ]. "<br/>!" ;
echo "href="process.php?action=logout"> <a Sair </ a> </ p> ' ;
}
mais {
?>
<Form action = "process.php ação? = login" method = "post" >
<p> O nome de usuário é: admin </ p>
<Input type = "text" name = "user" size = "20" />
<p> A senha é: teste </ p>
<Input type = "password" name = "pass" size = "20" />
<Input type = "submit" value = "Login" />
</ Form>
<? Php
}
?>
</ Body>
</ Html>
O login.php roteiro começa por inicializar os dados da sessão. Em seguida, ele verifica se $ _SESSION ["user"] foi definido, e se estiver, exibe uma mensagem de boas vindas junto com um link para logout. Caso contrário, exibe o formulário de login.
Este é o script de processamento, process.php :
<? Php
session_start ();
interruptor ( $ _GET [ "action" ]) {
caso "login" :
se ( $ _SERVER [ "REQUEST_METHOD" ] == "POST" ) {
$ User = (isset ( $ _POST [ "user" ]) & &
ctype_alnum ( $ _POST [ "user" ?]) $ _POST [ "user" ]: null;
$ Pass = (isset ( $ _POST [ "pass" ?])) $ _POST [ "pass"]: null;
$ Salt = '$ 2a $ 07 $ $ my.s3cr3t.SalTY.str1nG' ;
se (isset ( $ user , $ pass ) & & (crypt ( $ user . $ pass, $ salt ) ==
crypt ( "admintest" , $ salt ))) {
$ _SESSION [ "user" ] = $ _POST [ "user" ];
}
}
quebrar ;
caso "logout" :
$ _SESSION = matriz ();
session_destroy ();
quebrar ;
}
header ( "Location: login.php" );
?>
O process.php script também começa por inicializar os dados da sessão, e depois verifica se há uma ação para trabalhar. Realizamos algumas validações básicas de entrada usando PHPoperador ternário , juntamente com o ctype_alnum () e crpyt () funções, e em seguida, definir ou destruir a variável de sessão em conformidade. O usuário é redirecionado de volta paralogin.php no final do script.
Agora vamos nos concentrar no arquivo de um atacante poderia criar para explorar o código em nossos exemplos anteriores. Este é o código de exploração, harmless.html :
< html >
< corpo >
< p > Esta página é inofensivo ... Ou é? </ p >
<! - Endereço para atingir site ->
< img src = "ação process.php = sair?" estilo = "display: none;" />
</ corpo >
</ html >
Se você visitar login.php e efetue login na sua conta, e depois enquanto estiver conectado você continuar a visitar a página do atacante, você será desconectado automaticamente mesmo que você não clique no link de logout. O navegador envia uma solicitação para o servidor para acessar o process.php script, esperando que ele seja um arquivo de imagem. O script de processamento não tem nenhuma maneira de diferenciar entre um pedido válido iniciado por um usuário clicando no link de logout e um pedido habilmente trabalhada o navegador foi enganado e envio.
O harmless.html arquivo pode ser hospedado em um servidor totalmente diferente daquele que você está conectado, e seria ainda o trabalho porque a página do atacante é fazer um pedido em seu nome usando a sessão que foi aberta em segundo plano. Nem sequer importa se o site que você está conectado está em uma rede privada, o pedido será submetido a partir do seu endereço de IP como se você fez o pedido a si mesmo, fazendo um rastreamento para a fonte do ataque quase impossível.
Além disso, se você permitir que seus usuários o link para as imagens como um avatar de perfil ou similar, sem a devida escapar e desinfecção do usuário dados fornecidos o ataque pode até ser possível dentro do seu domínio próprio web.
Ao registrar alguém fora de um site não é que, impressionante harmless.html poderia ter apenas como facilmente continha um frame inline escondido (em oposição a uma tag de imagem) com um formulário que envia automaticamente quando a página é carregada, o que tornaria qualquer dos ataques mencionados no início deste jogo justo guia.
Espero que agora você entende o quão sérios ataques CSRF pode ser, então vamos dar uma olhada em como você pode evitá-las.
Proteger seus usuários
A fim de assegurar que uma ação está realmente sendo executada pelo usuário, em vez de uma terceira pessoa, você precisa associá-lo com algum tipo de identificador único que pode então ser verificada. Para evitar o ataque, podemos modificar login.php como segue:
<? Php
/ / Fazer um id aleatório
$ _SESSION [ "token" ] = md5 (uniqid (mt_rand (), true));
echo "<a href =" process.php action = & Sair csrf =? ' . $ _SESSION["token "]. '" > Sair </ a> </ p> ';
Em seguida, para verificar o identificador, podemos modificar process.php da seguinte forma:
caso "logout" :
se (isset ( $ _GET [ "csrf" ]) & & $ _GET [ "csrf" ] == $ _SESSION[ "token" ]) {
$ _SESSION = matriz ();
session_destroy ();
}
quebrar ;
Com estas modificações simples, harmless.html deixarão de funcionar porque o atacante tem sido dada a tarefa adicional de ter que adivinhar um valor simbólico adicional aleatório. Para proteger os formulários, você também pode incluir o interior identificador de um campo oculto da seguinte forma em que for apresentado juntamente com o resto dos dados do formulário.
< input tipo = "hidden" name = "csrf" valor = "<? php echo $ _SESSION [" token "];?>" />
Na minha opinião, apesar das melhores intenções assédio dos meus amigos e colegas estimado, eu prefiro usar PHP session_id () em vez de gerar um token aleatória já que eu não sou particularmente apaixonado da "segurança pela obscuridade" abordagem. Além de utilizarsession_id () , eu também uso session_regenerate_id () sempre que o login ou atualização de informações sigilosas, a fim de mitigar o risco de ataques de fixação de sessão, e eu nunca acrescentar a ID para uma URL que serão armazenados na história dos navegadores .Arbitrariamente expondo o id de sessão mais do que o necessário nunca é uma boa idéia, mas enquanto você estiver atento Eu acho que é uma abordagem mais elegante. É claro que, se o site usa algum tipo de autenticação que não usa sessões, então você precisa gerar sua própria identificação de qualquer maneira.
Conclusão
Até agora você deve compreender os princípios básicos subjacentes a um ataque de CSRF e quais os passos que você pode tomar para proteger seu site e seus usuários. Como Ben Franklin disse, "uma onça de prevenção vale um quilo de cura." Tenho certeza que todos nós prefere tomar o tempo para certificar-se de escrever o código que está seguro do que lidar com o stress, dores de cabeça e possíveis processos judiciais ao redor um compromisso.
Nenhum comentário :
Postar um comentário