Cookies como uma ameaça: Falsificação de  solicitação entre sites

7 min.
Ataques WordPress de Pedidos de Falsificação Cruzada (CSRF) estão entre os mais antigos ataques de sempre.

CSRF, este acrónimo aparece repetidamente nas atualizações de segurança e manutenção do núcleo do WordPress. O método por trás dele é agora antigo e usa os cookies abundantes de um utilizador da Internet. Felizmente, é bastante fácil protegermo-nos da Falsificação de Solicitações entre Sites (CSRF). Tudo o que precisas é de um pouco de tempo e atenção.

Provavelmente você também usa uma série de serviços onde existe a opção de permanecer conectado mesmo depois de ter deixado o site. Se você visitar o site novamente, você não terá que digitar seus dados de login novamente, mas será logado diretamente. Isto é óptimo para o utilizador, porque é - tal como uma gestão de senhas ou uma chamada Single Sign-On - preenchimento cansativo do formulário.

Acontece o seguinte em segundo plano: Quando você entra no site pela primeira vez, o site armazena um cookie no seu navegador. Este é um pequeno arquivo de texto no qual certas informações podem ser armazenadas. Se você ficar logado, é uma cadeia de caracteres gerada aleatoriamente.

Da próxima vez que visitar o site, o servidor verifica esta cadeia de caracteres e, se conseguir encontrar a contrapartida correspondente, regista-o automaticamente. A propósito, esta é a razão pela qual você será desconectado de todos os lugares, quando você tiver Cache do Navegador vazio. Isto acontece porque todos os cookies também são eliminados durante este processo.

Um ataque do CSRF é essencialmente um abuso de confiança

Já reparaste: No caso de um ataque correspondente, o atacante finge ser o serviço que lê os cookies. Vou explicar exatamente como isso acontece usando dois exemplos abaixo.

O perigo desta manipulação reside no facto de um terceiro, ou seja, o atacante, por exemplo, fazer alterações ao seu perfil no Facebook em seu nome. No entanto, a falsificação de pedidos entre locais também depende muitas vezes do phishing. Aqui, também, a confiança torna-se relevante - a sua confiança no remetente de e-mails, por exemplo.

Os ataques de Cross Site Request Forgery (CSRF) WordPress podem ser evitados pelo senso comum.

Quão ameaçado está WordPress ?

Você provavelmente não ouviu o termo Cross-Site Request Forgery tão frequentemente quanto Brute Force Ataques ou roteiro cruzado. Há uma razão para isso: a organização sem fins lucrativos OWASP (Open Web Application Security Project) publica regularmente uma lista das dez vulnerabilidades mais críticas nas aplicações web. No lista preliminar para 2017 O CSRF ocupa o 8º lugar entre os 10. Em 2007 e 2010 o ataque ainda aterrissou no 5º lugar, Em 2013 subiu para o 8º lugar desligado.

Uma razão para isso é provavelmente que os ataques do CSRF são quase tão antigos quanto a própria Internet. Os desenvolvedores profissionais estão agora habilitados a proteger o seu código contra eles. Os riscos de segurança são, portanto, fácil e rapidamente corrigidos.

Com WordPress um também está de guarda. Por exemplo, a atualização de segurança 4.7.5 foi lançada em maio, que corrigiu seis vulnerabilidades que poderiam ter sido usadas por hackers para lançar um ataque via cross-site scripting ou cross-site request forgery. Frequentemente mas ainda assim roteiro cruzado é considerado muito mais perigoso.

Além disso, a questão da Falsificação de Pedido Cruzado tende a ser mais relevante para Plugin- e desenvolvedores de aplicativos do que para web designers, agências e PMEs. Porque a proteção contra o CSRF também é uma questão de programação. O QRSRQ pode ser relevante, por exemplo, para...Plugin-...será comprado.

Mas como funciona tudo isso agora?

A anatomia da Falsificação de Pedido Cross-Site

A ideia básica por detrás de um ataque CSRF é relativamente simples e normalmente acontece em duas etapas:

  1. O hacker faz a vítima carregar uma página manipulada ou clicar em um link, por exemplo, fingindo ser uma pessoa de confiança ou explorando a curiosidade humana. Em outras palavras, o phishing desempenha um papel importante neste tipo de ataque.
  2. Ao carregar ou clicar nas ligações ou páginas manipuladas, o navegador da vítima executa um pedido HTTP sem que a vítima se aperceba.

Dois exemplos relativamente simples ilustram como um ataque deste tipo funciona.

Vamos assumir que o Justus quer levar o Bob até ao local. www.bank.de Transfira 100 euros, e Skinny estará atento a um ataque de CSRF. Skinny pode agora usar o método GET ou POST para o seu ataque.

A propósito, os seguintes exemplos provêm das seguintes fontes:

Falsificação para o método GET

O método GET é usado para solicitar um recurso de um servidor, por exemplo, um arquivo HTML. Os parâmetros necessários para a chamada são simplesmente adicionados ao URL. E como já ouvimos de Injeções SQL Sabe: Um URL é relativamente fácil de manipular.

Então Justus entra no www.bank.de e introduz todos os dados necessários. As seguintes entradas (completamente fictícias) seriam transmitidas para o servidor:

GET http://bank.de/transfer.do?acct=BOBetrag=100 HTTP/1.1

Skinny agora constrói um URL que transfere 100.000 euros para a sua própria conta. Parece que é assim:

http://bank.de/transfer.do?acct=SKINNYetrag=100000

Claro que o Justus tem de executar a acção escondida por detrás do elo falso. Portanto, Skinny envia ao Justus um e-mail com um link falso. O código HTML poderia ser parecido com este, por exemplo:

"Se não consegues resolver este mistério, não és um detective a sério!

Ou envia-lhe um e-mail contendo uma imagem "invisível" (porque 0 por 0 pixels). Ao tentar carregar a imagem, o navegador acessa a URL sem que Justus sequer perceba:

Quando Justus chama o link - consciente ou inconscientemente - os parâmetros são transferidos para o servidor, a transferência é iniciada e 100.000 euros desaparecem da sua conta.

É claro que Justus tem de clicar no link enquanto está conectado. Mas se infelizmente há um cookie de login do seu banco no seu navegador. o ataque funciona mesmo que ele ainda não tenha aberto a página na altura.

Isto é exactamente o que torna o Cross-Site Request Forgery tão desonesto: o lesado pode nem sequer saber que o cookie existe.

Falsificação de pedido entre locais com o método POST

O método GET pode ser usado em links e é, portanto, particularmente fácil de espalhar. Isto joga naturalmente nas mãos do atacante em termos de distribuição. Agora, no entanto, os provedores podem garantir que os pedidos de GET não recebam, por princípio, permissão de escrita.

O método POST permanece: Aqui os dados são transferidos para um servidor para que possam ser processados posteriormente. Os dados não fazem parte do URL, mas são anexados ao cabeçalho.

Pode parecer um pouco volumoso, mas tenho a certeza que conhece a candidatura. Porque os formulários funcionam desta forma.

Para o nosso atacante, Skinny, isso significa que, embora ele tenha que fazer mais esforço, ele ainda pode alcançar seu objetivo.

O mesmo cenário: Justus quer transferir dinheiro para o Bob. Então ele preenche www.bank.com a seguinte forma:

<formulário método="PÓS" ação="wire_transfer.php">

    <entrada tipo="texto" nome="de">

    <entrada tipo="texto" nome="ligado">

    <entrada tipo="texto" nome="montante_em_euro">

    <entrada tipo="submeter">

formulário>

Isto envia o comando geld_ueberweisung.php que se parece com isto

se(isset($_FORM["de"]) && isset($_FORM["ligado"]) &&isset($_FORM["crowd_in_euro"]) && isset($_CMOKIE["user_logged in"]))

{

    transMoney("de", "ligado", "quantia");

    echo "Transferência bem sucedida!";

}

Como podes ver, o código usa os cookies para verificar primeiro se o Justus está conetado. A transferência só será realizada se for esse o caso.

Skinny agora deposita uma forma invisível em um site manipulado, por exemplo

<formulário método="PÓS" ação="http://www.bank.de/geld_ueberweisen.php">

    <entrada tipo="texto" nome="de" valor="Justus"... estilo="Mostrar: oculto">

    <entrada tipo="texto" nome="ligado" valor="Magricela". estilo="Mostrar: oculto">

    <entrada tipo="texto" nome="montante_em_euro" valor="100000" estilo="Mostrar: oculto">

    <entrada tipo="submeter" valor="Aquele que não consegue resolver este mistério não é um detective a sério!">

formulário>

Ele envia o link para este site manipulado para o Justus. Sentindo-se desafiado, ele clica no botão para ver o puzzle; e executa involuntariamente a função geld_ueberweisung.php. Como encontra um cookie correspondente no seu navegador, 100.000 euros são novamente transferidos para Skinny.

ataque por meios desonestos

Daí o nome Cruz-Site Request Forgery: O hacker geralmente envia o comando a partir de outro site. A fim de atacar o lado A, ele deposita código malicioso no lado B. Ele então atrai aqui o usuário insuspeito para que o seu navegador execute o código.

Quão perigosos são os ataques de Cross Site Request Forgery (CSRF) WordPress ?

Como se proteger contra os ataques do CSRF

A boa notícia: A Falsificação de Pedidos em Cross-Site já existe há muito tempo. Os desenvolvedores conhecem o risco e estão trabalhando arduamente para eliminá-lo.

A má notícia é que você não pode realmente se proteger contra isso no lado técnico. O WordPress -Core está agora relativamente bem protegido, e como pode ver pelas actualizações em curso, está constantemente a ser trabalhado. Como com outros tipos de ataques, a maioria das vulnerabilidades vem com Pluginsele. Portanto, você tem que confiar que os desenvolvedores das extensões que você usa estão fazendo um bom trabalho.

Isto significa concretamente:

  • Não instale demasiados Plugins e apenas o Pluginsque você realmente precisa
  • Cuidado com Pluginsaqueles que não foram atualizados pelos desenvolvedores por muito tempo. As falhas de segurança não resolvidas podem ser escondidas aqui.
  • Informe-se com antecedência sobre a Pluginsque você instala, por exemplo, sobre sua compatibilidade com outros Plugins ou a WordPress versão que você está usando (para que Pluginpossa ser atualizada).
  • Actualize regularmente o seu WP-Core Pluginse o seu WP-Core. Porque as atualizações contínuas estão exatamente lá para fechar tais buracos de segurança.
  • Você é crítico em relação ao phishing.
  • Se você não tem certeza, dê uma olhada. Plugin no repositório WP. Quais são as classificações, quais foram os maiores problemas no passado, e fizeram a Plugin uma quebra de segurança de alto nível pode não ter sido fechada?

Conclusão: o CSRF é um chapéu velho

A Falsificação de Pedidos em Cross-Site existe praticamente desde o início da era digital. Além disso, o número de casos aumentou em comparação, por exemplo, com Brute Force Ataques extremamente pequeno.

Isto também confirma a avaliação da OWASPAqui, assume-se que o ataque é bastante pequeno, fácil de detectar e apenas em certos casos específicos grave é.

Mesmo assim, é bom saber como funcionam os ataques. Porque muitas vezes os ataques só funcionam graças ao erro humano. Uma e outra vez, por curiosidade, os usuários abrem mails ou clicam em links que não deveriam ter aberto.

Portanto, seja você um usuário ou um operador, a melhor maneira de se proteger da Falsificação de Pedido Cross-Site é usar a pesquisa e um pouco de senso comum.

Artigos relacionados

Comentários sobre este artigo

Escreve um comentário

O teu endereço de e-mail não será publicado. Os campos obrigatórios estão marcados com * .