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

Tobias Schüring Última actualização 21.01.2020
7 min.
Ataques de Pedidos de Falsificação Cruzada (CSRF) em WordPress  estão entre os ataques mais antigos de todos.

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 que lhe dão a opção de permanecer logado mesmo depois de ter saído do site. Se você então visitar a página novamente, você não precisa digitar seus dados de login novamente, mas está logado diretamente. Para o utilizador, é claro que isto é óptimo, porque - tal como a gestão de uma palavra-passe ou o chamado Single Sign On - poupa o incómodo preenchimento de formulários.

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. No caso de permanecer conectado, esta é 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. Esta é também a razão pela qual você está desconectado em qualquer lugar quando você limpa o cache do seu navegador. Porque todos os cookies também são eliminados durante este processo.

Um ataque do CSRF é, no seu âmago, 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, fazer alterações ao seu perfil no Facebook em seu nome, por exemplo. No entanto, o pedido de falsificação cruzada no local também depende muitas vezes do phishing. Também aqui a confiança se torna relevante - nomeadamente a sua confiança, por exemplo, nos remetentes de e-mails.

Falsificação de Pedido Cruzado de Local (CSRF) Os ataques em WordPress  podem ser evitados pelo senso comum.

Quão vulnerável é 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. Na 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, caiu para o número oito. descido.

Isto deve-se provavelmente em parte ao fato de que os ataques do CSRF são quase tão antigos quanto a própria Internet. Os desenvolvedores profissionais são agora bem praticados em proteger seu código contra eles. Portanto, os riscos de segurança são bastante fáceis e rápidos de reparar.

WordPress também está de vigia. Por exemplo, a atualização de segurança 4.7.5 foi lançada em maio, que corrigiu seis vulnerabilidades que os hackers poderiam ter usado para lançar um ataque via cross-site scripting ou cross-site request forgery. Muitas vezes A escrita cruzada é muitas vezes considerada muito mais perigosa.

Além disso, a questão da falsificação de pedidos entre sites tende a ser mais relevante para Plugin- e desenvolvedores de aplicativos do que para web designers, agências e PMEs. Isto porque a proteção contra o CSRF também é uma questão de programação. A CSRF pode tornar-se relevante, por exemplo, no caso de compras emPlugin.

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 engana a vítima para carregar uma página manipulada ou clicar em um link, por exemplo, fazendo-se passar por uma pessoa de confiança ou explorando a curiosidade humana. Em outras palavras, o phishing desempenha um papel importante neste tipo de ataque.
  2. Quando as ligações ou páginas manipuladas são carregadas ou clicadas, o navegador da vítima executa um pedido HTTP sem que a vítima dê por isso.

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

Para isso, vamos assumir que Justus quer enviar uma mensagem ao Bob através da página www.bank.de 100 euros, e Skinny está sentado à espera para realizar um ataque CSRF. Skinny pode agora usar, por exemplo, o método GET ou POST para o seu ataque.

A propósito, os exemplos a seguir são das seguintes fontes:

Falsificação de Pedido Cruzado com 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 anexados ao URL. E como já sabemos pelas injecções SQL: 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=BOB&betrag=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=SKINNY&betrag=100000

Claro, Justus tem que realizar a ação escondida atrás do elo falso. Portanto, o Skinny envia ao Justus um correio com um link falso. O código HTML pode ter este aspecto, por exemplo:

">Quem não consegue resolver este mistério não é um detective a sério!

Ou ele lhe envia um e-mail que contém 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 passados para o servidor, a transferência é acionada e 100.000 euros desaparecem de sua conta.

É claro que Justus tem de clicar no link enquanto estiver logado. Mas se, infelizmente, o seu navegador contém um cookie de login do seu banco o ataque funciona mesmo que ele não tenha aberto a página.

É exatamente isso que torna o pedido de falsificação cruzada tão insidioso: a vítima pode nem mesmo 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, em princípio, permissão de escrita.

O método POST permanece: Aqui, os dados são transferidos para um servidor para que ele possa processá-los posteriormente. Os dados não fazem parte do URL, mas são anexados ao cabeçalho.

Pode parecer um pouco volumoso, mas você certamente conhece o caso de uso. Porque os formulários funcionam desta forma.

Para o nosso atacante, Skinny, isso significa que ele tem que se esforçar mais, mas ele ainda pode chegar onde está indo.

O mesmo cenário: Justus quer transferir dinheiro para o Bob. Então ele preenche www.bank.de e preenche o seguinte formulário:

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

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

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

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

    <entrada tipo="submeter">

formulário>

Isto envia o comando money_transfer.php, que se parece com isto:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

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 uma página da web manipulada, 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="an" valor="magricela" estilo="Mostrar: oculto">

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

    <entrada tipo="submeter" valor="Quem 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. Ele se sente desafiado, clica no botão para ver o quebra-cabeça e, sem saber, executa a função geld_ueberweisen.php. Como isto encontra um cookie correspondente em seu navegador, 100.000 euros são transferidos para Skinny novamente.

Ataque através de desvios

É por isso que o nome CruzSite Request Forgery: O hacker geralmente envia o comando a partir de outro site. A fim de atacar a página A, ele deposita código malicioso na página B. Então ele 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) em WordPress ?

Como se proteger contra os ataques do CSRF

A boa notícia é que o pedido de falsificação cruzada já existe há muito tempo. Os desenvolvedores conhecem o risco e estão trabalhando especificamente para eliminá-lo.

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

Isso significa especificamente:

  • Não instale muitos Plugins e apenas o Plugins que você realmente precisa.
  • Tenha cuidado com Plugins, que não foi atualizado pelos desenvolvedores por algum tempo. Vulnerabilidades de segurança não corrigidas podem estar escondidas aqui.
  • Verifique a compatibilidade do Plugins que está a instalar com outro Plugins ou a versão WordPress que está a utilizar (para que o Plugin possa ser actualizado).
  • Actualize regularmente o seu núcleo Plugins e WP. Porque as atualizações contínuas estão exatamente lá para fechar tais falhas de segurança.
  • Você é crítico em termos de phishing
  • Se você não tem certeza, dê uma olhada de perto em Plugin no repositório WP. Quais são as classificações, quais têm sido os maiores problemas no passado e o Plugin possivelmente não fechou um buraco de segurança proeminente?

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

Desde o início da era digital que existe um pedido de falsificação cruzada. Além disso, o número de casos é extremamente pequeno em comparação, por exemplo, com os ataques do siteBrute Force .

Isto também é confirmado pela avaliação da OWASP de que o ataque é bastante baixo perfil, fácil de detectar e grave apenas em certos casos específicos. casos.

No entanto, é bom saber como funcionam os ataques. Porque os ataques muitas vezes só funcionam graças ao erro humano. Uma e outra vez, os usuários abrem e-mails por curiosidade ou clicam em links que teriam sido melhores se não tivessem aberto.

Portanto, seja você um usuário ou um usuário final, a melhor maneira de se proteger de pedidos de falsificação cruzada no local é com pesquisa e um pouco de bom senso.

Como administrador do sistema, Tobias zela pela nossa infraestrutura e faz os ajustes necessários para otimizar o desempenho dos nossos servidores. Devido ao seu esforço incansável, ele pode ser frequentemente encontrado na Slack, a nossa "sala de chat da empresa".

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 *.